En fait je recherche l'intersection d'un polygone avec un cadre
rectangulaire.
Je ne peux pas utiliser les API rgn car il s'agit de trouver cette
interscetion en ignorant ce qui se passe en dehors du rectangle. On
seulemnt les points du polygone qui sont à l'intérieur du rectangle et
d'entrée et de sortie du rectangle.
D'après mes recherches, j'ai vu qu'il me fallait connaitre l'intersection
d'un côté du polygone avec le rectangle ce qui peut donner 0, 1 ou deux
points. De plus, imposer le sens de parcours du polygone, semble
les calculs, le côté est donc un segment orienté. Dans le cas des deux
points il me faut récupérer le plus près de l'origine du segment.
Je suis loin d'avoir résolu tous les problèmes, en particulier pour un
polygone dont le pourtour est entièrement en dehors du rectangle, comment
différencier les cas ou le rectangle est à l'intérieur du polygone
(grosso-modo un rectangle dans un cercle) de celui où il est à l'extérieur
du polygone (cas limite, un rectangle dans une couronne).
Merci de vous intéresser à mon problème.
Pour ce qui concerne "le cycle du programme", en fait pour la majorité des
évènements concernant ma forme ou l'un de ses composants (clic,
...) un calcul utilisant la fonction précitée se lance pour chaque point
d'un tableau de 30000 points.
"Jean-Marc" a écrit dans le message de
41e11f4c$0$14670$
> "Patrice Henrio" a écrit dans le message de
> news:%
>> Je n'en suis pas sûr, je vous joins le code
>
> // le code
>
> Hello,
>
> je ne suis pas un expert en mathématique, mais je sais qu'il y a plus
> efficace (moins d'operations arithmetiques) pour retrouver les
> coordonnées du point d'intersection de 2 segments. Cependant, les
> fonctions usuelles retournent les coordonnées cartésiennes du point
> d'intersection des 2 segments, et non pas comme dans cette fonction
> l'abscisse barycentrique. Je ne sais pas si le fait de connaitre cette
> abscisse barycentrique est une contrainte liée à la suite des calculs.
> Je ne peux donc pas juger de l'efficacité ni de l'utilité de cet algo.
>
> 2 choses:
>
> - il existe sur le Net des centaines de pages traitant de
> l'intersection de segments. Une recherche avec:
> 'better algorithm segment intersection' dans Google donne
> tout un tas de résultats intéressants. Voir aussi Knuth et les autres.
>
> - le groupe de mathematiques (fr.sci.maths) est plein d'experts!
>
> - tel qu'il est, cet algo me semble tout à fait adapté à un portage en
> C (il n'utilise pas de fonctions trigonométriques, etc).
>
> Si les performances n'étaient pas suffisantes, alors il faudrait
> envisager d'autres solutions.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
En fait je recherche l'intersection d'un polygone avec un cadre
rectangulaire.
Je ne peux pas utiliser les API rgn car il s'agit de trouver cette
interscetion en ignorant ce qui se passe en dehors du rectangle. On
seulemnt les points du polygone qui sont à l'intérieur du rectangle et
d'entrée et de sortie du rectangle.
D'après mes recherches, j'ai vu qu'il me fallait connaitre l'intersection
d'un côté du polygone avec le rectangle ce qui peut donner 0, 1 ou deux
points. De plus, imposer le sens de parcours du polygone, semble
les calculs, le côté est donc un segment orienté. Dans le cas des deux
points il me faut récupérer le plus près de l'origine du segment.
Je suis loin d'avoir résolu tous les problèmes, en particulier pour un
polygone dont le pourtour est entièrement en dehors du rectangle, comment
différencier les cas ou le rectangle est à l'intérieur du polygone
(grosso-modo un rectangle dans un cercle) de celui où il est à l'extérieur
du polygone (cas limite, un rectangle dans une couronne).
Merci de vous intéresser à mon problème.
Pour ce qui concerne "le cycle du programme", en fait pour la majorité des
évènements concernant ma forme ou l'un de ses composants (clic,
...) un calcul utilisant la fonction précitée se lance pour chaque point
d'un tableau de 30000 points.
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de
41e11f4c$0$14670$ba620e4c@news.skynet.be...
> "Patrice Henrio" <patrice.henrio@laposte.net> a écrit dans le message de
> news:%23PsGo0j9EHA.1188@tk2msftngp13.phx.gbl...
>> Je n'en suis pas sûr, je vous joins le code
>
> // le code
>
> Hello,
>
> je ne suis pas un expert en mathématique, mais je sais qu'il y a plus
> efficace (moins d'operations arithmetiques) pour retrouver les
> coordonnées du point d'intersection de 2 segments. Cependant, les
> fonctions usuelles retournent les coordonnées cartésiennes du point
> d'intersection des 2 segments, et non pas comme dans cette fonction
> l'abscisse barycentrique. Je ne sais pas si le fait de connaitre cette
> abscisse barycentrique est une contrainte liée à la suite des calculs.
> Je ne peux donc pas juger de l'efficacité ni de l'utilité de cet algo.
>
> 2 choses:
>
> - il existe sur le Net des centaines de pages traitant de
> l'intersection de segments. Une recherche avec:
> 'better algorithm segment intersection' dans Google donne
> tout un tas de résultats intéressants. Voir aussi Knuth et les autres.
>
> - le groupe de mathematiques (fr.sci.maths) est plein d'experts!
>
> - tel qu'il est, cet algo me semble tout à fait adapté à un portage en
> C (il n'utilise pas de fonctions trigonométriques, etc).
>
> Si les performances n'étaient pas suffisantes, alors il faudrait
> envisager d'autres solutions.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
En fait je recherche l'intersection d'un polygone avec un cadre
rectangulaire.
Je ne peux pas utiliser les API rgn car il s'agit de trouver cette
interscetion en ignorant ce qui se passe en dehors du rectangle. On
seulemnt les points du polygone qui sont à l'intérieur du rectangle et
d'entrée et de sortie du rectangle.
D'après mes recherches, j'ai vu qu'il me fallait connaitre l'intersection
d'un côté du polygone avec le rectangle ce qui peut donner 0, 1 ou deux
points. De plus, imposer le sens de parcours du polygone, semble
les calculs, le côté est donc un segment orienté. Dans le cas des deux
points il me faut récupérer le plus près de l'origine du segment.
Je suis loin d'avoir résolu tous les problèmes, en particulier pour un
polygone dont le pourtour est entièrement en dehors du rectangle, comment
différencier les cas ou le rectangle est à l'intérieur du polygone
(grosso-modo un rectangle dans un cercle) de celui où il est à l'extérieur
du polygone (cas limite, un rectangle dans une couronne).
Merci de vous intéresser à mon problème.
Pour ce qui concerne "le cycle du programme", en fait pour la majorité des
évènements concernant ma forme ou l'un de ses composants (clic,
...) un calcul utilisant la fonction précitée se lance pour chaque point
d'un tableau de 30000 points.
"Jean-Marc" a écrit dans le message de
41e11f4c$0$14670$
> "Patrice Henrio" a écrit dans le message de
> news:%
>> Je n'en suis pas sûr, je vous joins le code
>
> // le code
>
> Hello,
>
> je ne suis pas un expert en mathématique, mais je sais qu'il y a plus
> efficace (moins d'operations arithmetiques) pour retrouver les
> coordonnées du point d'intersection de 2 segments. Cependant, les
> fonctions usuelles retournent les coordonnées cartésiennes du point
> d'intersection des 2 segments, et non pas comme dans cette fonction
> l'abscisse barycentrique. Je ne sais pas si le fait de connaitre cette
> abscisse barycentrique est une contrainte liée à la suite des calculs.
> Je ne peux donc pas juger de l'efficacité ni de l'utilité de cet algo.
>
> 2 choses:
>
> - il existe sur le Net des centaines de pages traitant de
> l'intersection de segments. Une recherche avec:
> 'better algorithm segment intersection' dans Google donne
> tout un tas de résultats intéressants. Voir aussi Knuth et les autres.
>
> - le groupe de mathematiques (fr.sci.maths) est plein d'experts!
>
> - tel qu'il est, cet algo me semble tout à fait adapté à un portage en
> C (il n'utilise pas de fonctions trigonométriques, etc).
>
> Si les performances n'étaient pas suffisantes, alors il faudrait
> envisager d'autres solutions.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
Je vois bien le probleme. Pour ce qui concerne la question initiale
(VB/C) pour les calculs: avec l'algo que tu donnes, c'est sur et
certain que tu gagneras du temps si la fonction est en C: j'ai eu à
faire ce genre de choses pour un cas assez proche (quelques calculs
arithmetiques + quelques tests), et le résultat était sans appel: Gain
de l'ordre de 10 à 20 avec le C.
- Avant de faire le calcul d'intersection, éliminer avec une méthode
rapide les segments qui ne peuvent pas intersecter: il existe des
méthodes très très rapides pour ça, basées sur les projections
orthogonales; en gros, tu projettes tes coordonnées sur les axes des X
et des Y. Si les projetés n'intersectent pas, alors les segments
n'intersectent pas non plus. Si les projetés en X n'intersectent pas,
tu sors. Sinon, tu projettes en Y; Si ça n'intersecte pas, tu sors. Si
Les 2 intersectent, alors tu calcules; tu élimines donc déja très
rapidement tous les cas pour lesquels tout calcul est inutile. Ces
fonctions pourront aussi être codées en C.
Le petit dessin illustre ceci:
B
+
| C
A | +
+ | |
^ | | | D
| | | | +
| | | | |
-+-------------------------------->
| a b c d
On voit bien qu'on peut très rapidement et sans calcul conclure que
[AB] et [CD] n'intersectent PAS, simplement en regardant les abscisses
des projetés orthogonaux sur l'axe des X; la même chose s'applique en
Y. Si les projetés intersectent en X ET en Y, alors il y a intersection
et on doit calculer.
- Penser à implémenter un mécanisme de cache: je suppose que tous les
segments ne bougent pas tous sans arrêt: on ne recalcule pas ce qui a
déjà été calculé. Ceci a un coût: qui dit cache dit mémoire pour le
cache. Cependant, si le temps de recherche dans le cache est inférieur
au temps de re calcul, ça peut valoir le coup (mais ça demande toujours
une étude au cas par cas).
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"Patrice Henrio" a écrit dans le message de
news:%En fait je recherche l'intersection d'un polygone avec un cadre
rectangulaire.
Je ne peux pas utiliser les API rgn car il s'agit de trouver cette
interscetion en ignorant ce qui se passe en dehors du rectangle. On
connaitseulemnt les points du polygone qui sont à l'intérieur du rectangle et
ceuxd'entrée et de sortie du rectangle.
D'après mes recherches, j'ai vu qu'il me fallait connaitre l'intersection
d'un côté du polygone avec le rectangle ce qui peut donner 0, 1 ou deux
points. De plus, imposer le sens de parcours du polygone, semble
simplifierles calculs, le côté est donc un segment orienté. Dans le cas des deux
points il me faut récupérer le plus près de l'origine du segment.
Je suis loin d'avoir résolu tous les problèmes, en particulier pour un
polygone dont le pourtour est entièrement en dehors du rectangle, comment
différencier les cas ou le rectangle est à l'intérieur du polygone
(grosso-modo un rectangle dans un cercle) de celui où il est à
l'extérieur
du polygone (cas limite, un rectangle dans une couronne).
Merci de vous intéresser à mon problème.
Pour ce qui concerne "le cycle du programme", en fait pour la majorité
des
évènements concernant ma forme ou l'un de ses composants (clic,
déplacement...) un calcul utilisant la fonction précitée se lance pour chaque point
d'un tableau de 30000 points.
"Jean-Marc" a écrit dans le message de
news:41e11f4c$0$14670$
> "Patrice Henrio" a écrit dans le message
> de
> news:%
>> Je n'en suis pas sûr, je vous joins le code
>
> // le code
>
> Hello,
>
> je ne suis pas un expert en mathématique, mais je sais qu'il y a
> plus
> efficace (moins d'operations arithmetiques) pour retrouver
> les
> coordonnées du point d'intersection de 2 segments. Cependant,
> les
> fonctions usuelles retournent les coordonnées cartésiennes du
> point
> d'intersection des 2 segments, et non pas comme dans cette
> fonction
> l'abscisse barycentrique. Je ne sais pas si le fait de connaitre
> cette
> abscisse barycentrique est une contrainte liée à la suite des
> calculs.
> Je ne peux donc pas juger de l'efficacité ni de l'utilité de cet algo.
>
> 2 choses:
>
> - il existe sur le Net des centaines de pages traitant de
> l'intersection de segments. Une recherche avec:
> 'better algorithm segment intersection' dans Google donne
> tout un tas de résultats intéressants. Voir aussi Knuth et les autres.
>
> - le groupe de mathematiques (fr.sci.maths) est plein d'experts!
>
> - tel qu'il est, cet algo me semble tout à fait adapté à un portage
> en
> C (il n'utilise pas de fonctions trigonométriques, etc).
>
> Si les performances n'étaient pas suffisantes, alors il
> faudrait
> envisager d'autres solutions.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
Je vois bien le probleme. Pour ce qui concerne la question initiale
(VB/C) pour les calculs: avec l'algo que tu donnes, c'est sur et
certain que tu gagneras du temps si la fonction est en C: j'ai eu à
faire ce genre de choses pour un cas assez proche (quelques calculs
arithmetiques + quelques tests), et le résultat était sans appel: Gain
de l'ordre de 10 à 20 avec le C.
- Avant de faire le calcul d'intersection, éliminer avec une méthode
rapide les segments qui ne peuvent pas intersecter: il existe des
méthodes très très rapides pour ça, basées sur les projections
orthogonales; en gros, tu projettes tes coordonnées sur les axes des X
et des Y. Si les projetés n'intersectent pas, alors les segments
n'intersectent pas non plus. Si les projetés en X n'intersectent pas,
tu sors. Sinon, tu projettes en Y; Si ça n'intersecte pas, tu sors. Si
Les 2 intersectent, alors tu calcules; tu élimines donc déja très
rapidement tous les cas pour lesquels tout calcul est inutile. Ces
fonctions pourront aussi être codées en C.
Le petit dessin illustre ceci:
B
+
| C
A | +
+ | |
^ | | | D
| | | | +
| | | | |
-+-------------------------------->
| a b c d
On voit bien qu'on peut très rapidement et sans calcul conclure que
[AB] et [CD] n'intersectent PAS, simplement en regardant les abscisses
des projetés orthogonaux sur l'axe des X; la même chose s'applique en
Y. Si les projetés intersectent en X ET en Y, alors il y a intersection
et on doit calculer.
- Penser à implémenter un mécanisme de cache: je suppose que tous les
segments ne bougent pas tous sans arrêt: on ne recalcule pas ce qui a
déjà été calculé. Ceci a un coût: qui dit cache dit mémoire pour le
cache. Cependant, si le temps de recherche dans le cache est inférieur
au temps de re calcul, ça peut valoir le coup (mais ça demande toujours
une étude au cas par cas).
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"Patrice Henrio" <patrice.henrio@laposte.net> a écrit dans le message de
news:%23lD4r6k9EHA.3504@TK2MSFTNGP12.phx.gbl...
En fait je recherche l'intersection d'un polygone avec un cadre
rectangulaire.
Je ne peux pas utiliser les API rgn car il s'agit de trouver cette
interscetion en ignorant ce qui se passe en dehors du rectangle. On
connait
seulemnt les points du polygone qui sont à l'intérieur du rectangle et
ceux
d'entrée et de sortie du rectangle.
D'après mes recherches, j'ai vu qu'il me fallait connaitre l'intersection
d'un côté du polygone avec le rectangle ce qui peut donner 0, 1 ou deux
points. De plus, imposer le sens de parcours du polygone, semble
simplifier
les calculs, le côté est donc un segment orienté. Dans le cas des deux
points il me faut récupérer le plus près de l'origine du segment.
Je suis loin d'avoir résolu tous les problèmes, en particulier pour un
polygone dont le pourtour est entièrement en dehors du rectangle, comment
différencier les cas ou le rectangle est à l'intérieur du polygone
(grosso-modo un rectangle dans un cercle) de celui où il est à
l'extérieur
du polygone (cas limite, un rectangle dans une couronne).
Merci de vous intéresser à mon problème.
Pour ce qui concerne "le cycle du programme", en fait pour la majorité
des
évènements concernant ma forme ou l'un de ses composants (clic,
déplacement
...) un calcul utilisant la fonction précitée se lance pour chaque point
d'un tableau de 30000 points.
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de
news:
41e11f4c$0$14670$ba620e4c@news.skynet.be...
> "Patrice Henrio" <patrice.henrio@laposte.net> a écrit dans le message
> de
> news:%23PsGo0j9EHA.1188@tk2msftngp13.phx.gbl...
>> Je n'en suis pas sûr, je vous joins le code
>
> // le code
>
> Hello,
>
> je ne suis pas un expert en mathématique, mais je sais qu'il y a
> plus
> efficace (moins d'operations arithmetiques) pour retrouver
> les
> coordonnées du point d'intersection de 2 segments. Cependant,
> les
> fonctions usuelles retournent les coordonnées cartésiennes du
> point
> d'intersection des 2 segments, et non pas comme dans cette
> fonction
> l'abscisse barycentrique. Je ne sais pas si le fait de connaitre
> cette
> abscisse barycentrique est une contrainte liée à la suite des
> calculs.
> Je ne peux donc pas juger de l'efficacité ni de l'utilité de cet algo.
>
> 2 choses:
>
> - il existe sur le Net des centaines de pages traitant de
> l'intersection de segments. Une recherche avec:
> 'better algorithm segment intersection' dans Google donne
> tout un tas de résultats intéressants. Voir aussi Knuth et les autres.
>
> - le groupe de mathematiques (fr.sci.maths) est plein d'experts!
>
> - tel qu'il est, cet algo me semble tout à fait adapté à un portage
> en
> C (il n'utilise pas de fonctions trigonométriques, etc).
>
> Si les performances n'étaient pas suffisantes, alors il
> faudrait
> envisager d'autres solutions.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
Je vois bien le probleme. Pour ce qui concerne la question initiale
(VB/C) pour les calculs: avec l'algo que tu donnes, c'est sur et
certain que tu gagneras du temps si la fonction est en C: j'ai eu à
faire ce genre de choses pour un cas assez proche (quelques calculs
arithmetiques + quelques tests), et le résultat était sans appel: Gain
de l'ordre de 10 à 20 avec le C.
- Avant de faire le calcul d'intersection, éliminer avec une méthode
rapide les segments qui ne peuvent pas intersecter: il existe des
méthodes très très rapides pour ça, basées sur les projections
orthogonales; en gros, tu projettes tes coordonnées sur les axes des X
et des Y. Si les projetés n'intersectent pas, alors les segments
n'intersectent pas non plus. Si les projetés en X n'intersectent pas,
tu sors. Sinon, tu projettes en Y; Si ça n'intersecte pas, tu sors. Si
Les 2 intersectent, alors tu calcules; tu élimines donc déja très
rapidement tous les cas pour lesquels tout calcul est inutile. Ces
fonctions pourront aussi être codées en C.
Le petit dessin illustre ceci:
B
+
| C
A | +
+ | |
^ | | | D
| | | | +
| | | | |
-+-------------------------------->
| a b c d
On voit bien qu'on peut très rapidement et sans calcul conclure que
[AB] et [CD] n'intersectent PAS, simplement en regardant les abscisses
des projetés orthogonaux sur l'axe des X; la même chose s'applique en
Y. Si les projetés intersectent en X ET en Y, alors il y a intersection
et on doit calculer.
- Penser à implémenter un mécanisme de cache: je suppose que tous les
segments ne bougent pas tous sans arrêt: on ne recalcule pas ce qui a
déjà été calculé. Ceci a un coût: qui dit cache dit mémoire pour le
cache. Cependant, si le temps de recherche dans le cache est inférieur
au temps de re calcul, ça peut valoir le coup (mais ça demande toujours
une étude au cas par cas).
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"Patrice Henrio" a écrit dans le message de
news:%En fait je recherche l'intersection d'un polygone avec un cadre
rectangulaire.
Je ne peux pas utiliser les API rgn car il s'agit de trouver cette
interscetion en ignorant ce qui se passe en dehors du rectangle. On
connaitseulemnt les points du polygone qui sont à l'intérieur du rectangle et
ceuxd'entrée et de sortie du rectangle.
D'après mes recherches, j'ai vu qu'il me fallait connaitre l'intersection
d'un côté du polygone avec le rectangle ce qui peut donner 0, 1 ou deux
points. De plus, imposer le sens de parcours du polygone, semble
simplifierles calculs, le côté est donc un segment orienté. Dans le cas des deux
points il me faut récupérer le plus près de l'origine du segment.
Je suis loin d'avoir résolu tous les problèmes, en particulier pour un
polygone dont le pourtour est entièrement en dehors du rectangle, comment
différencier les cas ou le rectangle est à l'intérieur du polygone
(grosso-modo un rectangle dans un cercle) de celui où il est à
l'extérieur
du polygone (cas limite, un rectangle dans une couronne).
Merci de vous intéresser à mon problème.
Pour ce qui concerne "le cycle du programme", en fait pour la majorité
des
évènements concernant ma forme ou l'un de ses composants (clic,
déplacement...) un calcul utilisant la fonction précitée se lance pour chaque point
d'un tableau de 30000 points.
"Jean-Marc" a écrit dans le message de
news:41e11f4c$0$14670$
> "Patrice Henrio" a écrit dans le message
> de
> news:%
>> Je n'en suis pas sûr, je vous joins le code
>
> // le code
>
> Hello,
>
> je ne suis pas un expert en mathématique, mais je sais qu'il y a
> plus
> efficace (moins d'operations arithmetiques) pour retrouver
> les
> coordonnées du point d'intersection de 2 segments. Cependant,
> les
> fonctions usuelles retournent les coordonnées cartésiennes du
> point
> d'intersection des 2 segments, et non pas comme dans cette
> fonction
> l'abscisse barycentrique. Je ne sais pas si le fait de connaitre
> cette
> abscisse barycentrique est une contrainte liée à la suite des
> calculs.
> Je ne peux donc pas juger de l'efficacité ni de l'utilité de cet algo.
>
> 2 choses:
>
> - il existe sur le Net des centaines de pages traitant de
> l'intersection de segments. Une recherche avec:
> 'better algorithm segment intersection' dans Google donne
> tout un tas de résultats intéressants. Voir aussi Knuth et les autres.
>
> - le groupe de mathematiques (fr.sci.maths) est plein d'experts!
>
> - tel qu'il est, cet algo me semble tout à fait adapté à un portage
> en
> C (il n'utilise pas de fonctions trigonométriques, etc).
>
> Si les performances n'étaient pas suffisantes, alors il
> faudrait
> envisager d'autres solutions.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>
Pour ma fonction d'intersection, je vais utiliser ta remarque sur les
projections. je la connaissais mais je ne pensais pas qu'elle pouvait être
utile ici. En fait elle est doublement utile puisque mon rectangle à ses
côtés parallèles aux axes, donc en deux tests je sais s'il y a 0 point
solution.
Encore merci.
Pour ma fonction d'intersection, je vais utiliser ta remarque sur les
projections. je la connaissais mais je ne pensais pas qu'elle pouvait être
utile ici. En fait elle est doublement utile puisque mon rectangle à ses
côtés parallèles aux axes, donc en deux tests je sais s'il y a 0 point
solution.
Encore merci.
Pour ma fonction d'intersection, je vais utiliser ta remarque sur les
projections. je la connaissais mais je ne pensais pas qu'elle pouvait être
utile ici. En fait elle est doublement utile puisque mon rectangle à ses
côtés parallèles aux axes, donc en deux tests je sais s'il y a 0 point
solution.
Encore merci.
J'ai besoin d'une fonction déterminant l'intersection de deux segments
(attention pas deux droites).
J'ai réalisé celle-ci dans mon programme.
Je voulais savoir si il y avait un avantage particulier (autre que le
partage du code) à créer une dll contenant cette fonction ou non :
rapidité d'exécution par exemple.
Si je réalise cette fonction en C++, vais-je réellement gagner du
temps ? Cette fonction est utilisée à peu près trente mille fois à
chaque cycle du programme principal.
J'ai besoin d'une fonction déterminant l'intersection de deux segments
(attention pas deux droites).
J'ai réalisé celle-ci dans mon programme.
Je voulais savoir si il y avait un avantage particulier (autre que le
partage du code) à créer une dll contenant cette fonction ou non :
rapidité d'exécution par exemple.
Si je réalise cette fonction en C++, vais-je réellement gagner du
temps ? Cette fonction est utilisée à peu près trente mille fois à
chaque cycle du programme principal.
J'ai besoin d'une fonction déterminant l'intersection de deux segments
(attention pas deux droites).
J'ai réalisé celle-ci dans mon programme.
Je voulais savoir si il y avait un avantage particulier (autre que le
partage du code) à créer une dll contenant cette fonction ou non :
rapidité d'exécution par exemple.
Si je réalise cette fonction en C++, vais-je réellement gagner du
temps ? Cette fonction est utilisée à peu près trente mille fois à
chaque cycle du programme principal.
Salut,
Peut-on voir ton code ?
Patrice Henrio wrote:J'ai besoin d'une fonction déterminant l'intersection de deux
segments (attention pas deux droites).
J'ai réalisé celle-ci dans mon programme.
Je voulais savoir si il y avait un avantage particulier (autre que le
partage du code) à créer une dll contenant cette fonction ou non :
rapidité d'exécution par exemple.
Si je réalise cette fonction en C++, vais-je réellement gagner du
temps ? Cette fonction est utilisée à peu près trente mille fois à
chaque cycle du programme principal.
Salut,
Peut-on voir ton code ?
Patrice Henrio wrote:
J'ai besoin d'une fonction déterminant l'intersection de deux
segments (attention pas deux droites).
J'ai réalisé celle-ci dans mon programme.
Je voulais savoir si il y avait un avantage particulier (autre que le
partage du code) à créer une dll contenant cette fonction ou non :
rapidité d'exécution par exemple.
Si je réalise cette fonction en C++, vais-je réellement gagner du
temps ? Cette fonction est utilisée à peu près trente mille fois à
chaque cycle du programme principal.
Salut,
Peut-on voir ton code ?
Patrice Henrio wrote:J'ai besoin d'une fonction déterminant l'intersection de deux
segments (attention pas deux droites).
J'ai réalisé celle-ci dans mon programme.
Je voulais savoir si il y avait un avantage particulier (autre que le
partage du code) à créer une dll contenant cette fonction ou non :
rapidité d'exécution par exemple.
Si je réalise cette fonction en C++, vais-je réellement gagner du
temps ? Cette fonction est utilisée à peu près trente mille fois à
chaque cycle du programme principal.
