Je suis l'auteur de l'article, je me permets donc de répondre.
C'est son algo. à la base qui est foireux : déjà utiliser un Set comme une structure totalement ordonnée c'est mathématiquement du grand n'importe quoi.
C'est littéralement la définition d'un std::set en C++ : « std::set is an associative container that contains a sorted set of unique objects » (cf la doc)
Un std::set C++ est totalement ordonné. Si tu prétends le contraire il va quand même falloir ramener de bons arguments, et me sortir un programme de contre-exemple où itérer sur le set ne te donne pas une séquence ordonnée…
Utiliser une fonction non injective pour construire la relation d'ordre est encore plus aberrant dans son cas.
Je ne vois pas en quoi la fonction est non-injective ? Chaque éléments est trié par déviation, et par index dans le cas où la déviation est égale. Chaque point ayant par définition un index différent, chaque élément de l'ensemble d'arrivé a bien au plus un antécédent, ce qui me semble être la définition d'une fonction injective ?
Un moyen simple aurait été de sélectionner tous les points qui ont la déviation minimale en 1 seule passe.
Si tu as un algo de simplification de polyligne plus optimal, n'hésite pas à le publier. Je me suis basé sur une variante (certes très simplifiée) de l'algo de Visvalingam–Whyatt, qui a priori est relativement efficace (voir Wikipédia).
Le résultat diffère toujours d'une machine à l'autre, mais si ça plante toujours alors c'est son algo qui est pas bon.
Ça plante à cause d'un comportement inattendu dû à des optimisations du processeur, et ça ne plante plus quand on a compris cela et qu'on a désactivé les optimisations, désolé si l'article n'est pas clair à ce sujet. L'algo fonctionne très bien, ne pas hésiter à le faire à la main sur papier pour s'en convaincre.
En effet en analyse numérique on admet une tolérance sur les calculs flottants et on apprend à être robuste là-dessus.
Je ne comprends pas cette remarque. L'analyse numérique, c'est vaste, sans parler des applications, donc j'ai tendance à me méfier des "on" très généralistes. Les biblios de calculs exacts (MPFR, GMP) n'utilisent pas de tolérance, par exemple, mais des représentations avec une précision variable et améliorable dynamiquement.
Et en l'occurrence, je ne vois toujours pas en quoi l'utilisation d'une tolérance dans mon cas réglerait le problème : au risque de me répéter, c'était un problème d’optimisation, qui a été résolu en désactivant les optimisations. Tout marche très bien maintenant, c'est tout à fait robuste, ça a tourné sur un paquet de polylignes en fournissant le résultat attendu sans plantage.
Oh, et déterministe ça ne veut pas dire « j'obtiens le même résultat partout tout le temps », ça veut dire : à conditions identiques j'obtiens le même résultat.
OK OK, j'admets avoir sans doute été abusif dans le terme déterministe. Bon j'ai quand même pu observer un même test dire vrai puis faux au sein d'un même run du même programme compilé sur la même plateforme à deux lignes d'écart. Mais OK, oui, techniquement chaque ligne était déterministe, donc admettons.
[^] # Re: Ahem
Posté par gee . En réponse au lien Comment j'ai rejoint la communauté du bug 323 [quand le bug vient du processeur]. Évalué à 10 (+11/-1).
Hello,
Je suis l'auteur de l'article, je me permets donc de répondre.
C'est littéralement la définition d'un
std::seten C++ : « std::set is an associative container that contains a sorted set of unique objects » (cf la doc)Un
std::setC++ est totalement ordonné. Si tu prétends le contraire il va quand même falloir ramener de bons arguments, et me sortir un programme de contre-exemple où itérer sur le set ne te donne pas une séquence ordonnée…Je ne vois pas en quoi la fonction est non-injective ? Chaque éléments est trié par déviation, et par index dans le cas où la déviation est égale. Chaque point ayant par définition un index différent, chaque élément de l'ensemble d'arrivé a bien au plus un antécédent, ce qui me semble être la définition d'une fonction injective ?
Si tu as un algo de simplification de polyligne plus optimal, n'hésite pas à le publier. Je me suis basé sur une variante (certes très simplifiée) de l'algo de Visvalingam–Whyatt, qui a priori est relativement efficace (voir Wikipédia).
Ça plante à cause d'un comportement inattendu dû à des optimisations du processeur, et ça ne plante plus quand on a compris cela et qu'on a désactivé les optimisations, désolé si l'article n'est pas clair à ce sujet. L'algo fonctionne très bien, ne pas hésiter à le faire à la main sur papier pour s'en convaincre.
Je ne comprends pas cette remarque. L'analyse numérique, c'est vaste, sans parler des applications, donc j'ai tendance à me méfier des "on" très généralistes. Les biblios de calculs exacts (MPFR, GMP) n'utilisent pas de tolérance, par exemple, mais des représentations avec une précision variable et améliorable dynamiquement.
Et en l'occurrence, je ne vois toujours pas en quoi l'utilisation d'une tolérance dans mon cas réglerait le problème : au risque de me répéter, c'était un problème d’optimisation, qui a été résolu en désactivant les optimisations. Tout marche très bien maintenant, c'est tout à fait robuste, ça a tourné sur un paquet de polylignes en fournissant le résultat attendu sans plantage.
OK OK, j'admets avoir sans doute été abusif dans le terme déterministe. Bon j'ai quand même pu observer un même test dire vrai puis faux au sein d'un même run du même programme compilé sur la même plateforme à deux lignes d'écart. Mais OK, oui, techniquement chaque ligne était déterministe, donc admettons.