Le topic de la programmation, string, chaînes, cuir et compagnie

[rOut]

...

Je regrette presque d'avoir posé la question.

[GrandFather]

C'est certain que cet extrait de code est... étonnant, maintenant je doute qu'il existe un développeur, aussi bon soit-il, exerçant dans des conditions professionnelles typiques (deadline impossible, clients acariâtres, patron obtus, spécifications incomplètes/absconses) qui n'ait pas sur la conscience un code un peu dégueu (mais fonctionnel) dont il a un peu honte. A cette aune, la seule différence entre bons et mauvais développeurs est la proportion de code moche par rapport à leur production totale, mais tous ont un cadavre dans le placard.

[war-p]

Certains en ont plus que d'autres...

Spoiler Alert!

Mais, c'est vrai que cette fonction est un peu WTF, surtout de la part de crytek : les commentaires bordel!

[TiNitro]

C'est certain que cet extrait de code est... étonnant, maintenant je doute qu'il existe un développeur, aussi bon soit-il, exerçant dans des conditions professionnelles typiques (deadline impossible, clients acariâtres, patron obtus, spécifications incomplètes/absconses) qui n'ait pas sur la conscience un code un peu dégueu (mais fonctionnel) dont il a un peu honte. A cette aune, la seule différence entre bons et mauvais développeurs est la proportion de code moche par rapport à leur production totale, mais tous ont un cadavre dans le placard.

Ah mais voui, bien d'accord, on en a tous. Par contre, du code comme ça qui apparaît dans une bibliothèque, donc visible des clients!! Des zaloberies j'en ai écrites pour les raisons que tu invoques, mais bordel un commentaire pour expliquer ce code ça aurait coûté, disons, 2 minutes ?

---------- Post added at 10h32 ---------- Previous post was at 10h27 ----------

Hélas

---------- Post added at 20h42 ---------- Previous post was at 20h41 ----------



J'ai pas d'opinion là dessus, mais tu as des infos sur le pourquoi ça ne sert à rien ces deux choses ?

Comparaison avec epsilon. Disons qu'à mon sens, les enseignants visent modeste: au moins certains étudiants retiendront qu'il ne faut pas comparer des flottants en utilisant == Après, le classique est d'utiliser un comparaison à tolérance relative, le vrai défi est de revoir les chaînes de calcul pour minimiser la propagation des erreurs d'arrondis, et en particulier en géométrie (CAO notamment, ou l'exigence de précision est sans commune mesure avec le jeu vidéo).

[rOut]

Ah mais voui, bien d'accord, on en a tous. Par contre, du code comme ça qui apparaît dans une bibliothèque, donc visible des clients!! Des zaloberies j'en ai écrites pour les raisons que tu invoques, mais bordel un commentaire pour expliquer ce code ça aurait coûté, disons, 2 minutes ?

Non mais surtout les zaloberies, tu les caches dans la cave, comme un enfant difforme.

Comparaison avec epsilon. Disons qu'à mon sens, les enseignants visent modeste: au moins certains étudiants retiendront qu'il ne faut pas comparer des flottants en utilisant == Après, le classique est d'utiliser un comparaison à tolérance relative, le vrai défi est de revoir les chaînes de calcul pour minimiser la propagation des erreurs d'arrondis, et en particulier en géométrie (CAO notamment, ou l'exigence de précision est sans commune mesure avec le jeu vidéo).

Møgluglu dit l'inverse, que quelque soit la situation, ton epsilon sera toujours mauvais donc autant faire un == directement (si j'ai bien compris son post, mais cette partie là ça allait encore )

[war-p]

Hmm, autant ne pas tenter de faire un comparaison == avec un flottant, histoire de gagner du temps.

[Le_CuLtO]

Comparaison avec epsilon. Disons qu'à mon sens, les enseignants visent modeste: au moins certains étudiants retiendront qu'il ne faut pas comparer des flottants en utilisant == Après, le classique est d'utiliser un comparaison à tolérance relative, le vrai défi est de revoir les chaînes de calcul pour minimiser la propagation des erreurs d'arrondis, et en particulier en géométrie (CAO notamment, ou l'exigence de précision est sans commune mesure avec le jeu vidéo).

En tout cas dans mon école on m'avait même pas avertit que le == marcherait pas forcément sur les flottants, je l'ai découvert sur le tas.
Bon ok c'était un DUT donc en 2 ans on a peut-être pas le temps de tout voir...

[war-p]

Ou alors, c'était des mauvais Non, sans rire, même en BTS, on le sait que ce genre de pratique, c'est comme les variables globales : généralement ça fini mal!

[GrandFather]

Non mais surtout les zaloberies, tu les caches dans la cave, comme un enfant difforme.

Celui qui a écrit ce code ne s'attendait peut-être pas non plus à ce qu'il soit rendu public. Il m'est arrivé la même mésaventure - toutes proportions gardées - quand j'ai écrit une application à l'arrache en un mois parce qu'elle était absolument nécessaire pour la certification ISO de ma boîte et que personne n'avait anticipé son besoin. C'est sorti juste à temps et ça fonctionnait mais je n'étais vraiment pas fier du résultat ; sentiment qui s'est transformé en véritable honte quand elle a été diffusée auprès des autres entreprises de la même institution dans le même cas que la nôtre et qu'il a fallu répondre aux questions techniques de mes collègues concernant tel ou tel choix de conception...

Le code moisi c'est comme les sous-vêtements de propreté douteuse, on souhaite les garder cachés mais on n'est jamais vraiment à l'abri d'un accident...

[TiNitro]

Møgluglu dit l'inverse, que quelque soit la situation, ton epsilon sera toujours mauvais donc autant faire un == directement (si j'ai bien compris son post, mais cette partie là ça allait encore )

Mogluglu dit que déterminer epsilon n'est pas une mince affaire, et comment il a raison. Je rappelais juste que la solution "classique" est d'utiliser une tolérance relative et j'ajouterais qu'il faut se poser la question de quelle doit être cette tolérance, ce qui fait quasiment partie de la spécification. Exemple: ma boite actuelle édite un logiciel de planification, les tests de comparaison de flottants sont soit des tests à zéro dans des algorithmes (tests de fin de boucle par exemple qu'on peut avantageusement remplacer par des <=) soit des test pour "nettoyer" l'affichage et la tolérance peut être très large voire configurable, c'est celle de l'utilisateur.


Dans une vie antérieure en CAO, c'était une autre paire de manche, et mes collègues qui ont eu à gérer ça se sont bien pris la tête à déterminer la bonne façon de comparer deux nombres.

[rOut]

Pour l'histoire de la comparaison de flottants, le gros problème vient de la conversion lors du stockage qui ne stocke pas exactement les valeurs qu'on lui a donné. Après si tu gardes ça en tête, je ne vois pas le problème. C'est pas pire qu'un epsilon qui va de toute manière exploser si tu enchaines les opérations sur tes flottants.

Si tu veux de la précision précise, mieux vaut utiliser une classe spécifiquement adaptée pour ça. En utilisant des rationnels plutôt que des flottants par exemple.

[GrandFather]

Dans une vie antérieure en CAO, c'était une autre paire de manche, et mes collègues qui ont eu à gérer ça se sont bien pris la tête à déterminer la bonne façon de comparer deux nombres.

Dans des domaines où les contraintes de précision sont bien moindres, tels le calcul financier non boursier par exemple, c'est heureusement bien plus facile à gérer: on décide à l'avance d'une précision fixe (le centième de centime d'euro par exemple), la règle d'arrondi, et on gère tout avec des entiers. Les comparaisons de nombres deviennent triviales.

[TiNitro]

Le gros problème ne vient pas seulement de la conversion, il vient du fait qu'à chaque opération il y a une erreur d'arrondi (idéalement sur le dernier bit de la mantisse) et que ces erreurs se propagent et s'amplifient. Et je ne parle pas de fonctions mathématiques comme les logarithmes ou les fonctions trigonométriques qui évidemment calculent des approximations.

Donc, si à la fin d'une chaîne de calculs tu as besoin de comparer deux nombres, la question est de savoir quelle est l'erreur potentielle sur ces nombres (résultant de la chaîne de calcul) ou encore quelle est l'approximation admissible d'un point de vue fonctionnel.

Les classes qui améliorent la précision (quadruple précision, rationnels) ne font que réduire le problème sans le résoudre, et au prix d'une dégradation abomiffreuse des performances. Il n'y a pas de représentation exacte d'un nombre irrationnel, on introduit nécessairement un erreur en les traitant.

P.S. le #define de PI est une chose que je ne critiquerais pas par contre dans le code qu'on a vu. Après tout, cela ne dégrade rien, ne pose pas de soucis de lisibilité, et permet de gérer justement des nombre dont la précision peut être plus grande. Ou est le problème ?

[war-p]

D'ailleurs, il vaut mieux définit les nombres réel PI,sqrt(2), phi etc... C'est plus... safe... Et ça permet de contrôler la source.

[rOut]

Le problème il est là: #define gf_PI f32(3.14159265358979323846264338327950288419716939937 510) // pi
Si tu veux garder le litéral PI pour l'utiliser avec différents types (f32, f64, f128...) ok, mais là tu lui coupes les jambes avant même de l'utiliser.

Sinon, effectivement à partir du moment ou tu utilises des nombres irrationnels tu te tapes les emmerdes.

[war-p]

Putains de cercles à la con...

[TiNitro]

@rOut: c'est vrai
@war-P: c'est vrai

[war-p]

Tu pouvais factoriser!

[Møgluglu]

Mogluglu dit que déterminer epsilon n'est pas une mince affaire, et comment il a raison.

Je vais plus loin que ça. Il y a des cas où une borne sur l'erreur absolue à un sens. Il y a d'autres cas où c'est l'erreur relative qui a un sens. Et puis il y a les cas où ni l'une ni l'autre n'a de sens. Hélas, c'est la grande majorité (tous les algos non triviaux en fait, dès que la sortie n'est pas une fonction linéaire des entrées.)
Dans ces cas, pour toute valeur d'epsilon choisie, on pourra toujours trouver à la fois des faux négatifs (résultats parfaitement légitimes qui sont rejetés) et des faux positifs (résultats totalement bidon qui sont acceptés). Le "bon" epsilon, il est dépendant des entrées.

C'est ce qui motive l'arithmétique d'intervalles, où on calcule des bornes sur les erreurs au fur et à mesure qu'on effectue le calcul lui-même. C'est très utile en temps qu'outil (notamment pour la géo-algo), mais il y a un certain nombre d'effets qui font que si on ne fait pas gaffe on se retrouve vite avec [-infini,+infini] comme intervalle en sortie.

Exemple: ma boite actuelle édite un logiciel de planification, les tests de comparaison de flottants sont soit des tests à zéro dans des algorithmes (tests de fin de boucle par exemple qu'on peut avantageusement remplacer par des <=) soit des test pour "nettoyer" l'affichage et la tolérance peut être très large voire configurable, c'est celle de l'utilisateur.

Les tests à zéro, ça ne garantit rien en général. Le signe du résultat d'un calcul peut être faux à cause des erreurs d'arrondi. Typiquement pour tous les calculs de déterminant, dès qu'on fait une soustraction entre deux nombre très proches entachés d'erreurs.

Les arrondis cosmétiques, ça sert à cacher les merdes sous le tapis pour que l'utilisateur ne les voient pas, et accessoirement ça rend le debuggage cauchemardesque. La majorité des bugs d'Excel viennent de là.

Dans des domaines où les contraintes de précision sont bien moindres, tels le calcul financier non boursier par exemple, c'est heureusement bien plus facile à gérer: on décide à l'avance d'une précision fixe (le centième de centime d'euro par exemple), la règle d'arrondi, et on gère tout avec des entiers. Les comparaisons de nombres deviennent triviales.

Les contraintes de précision sont moindre mais les contraintes légales sont un peu plus fortes.
Si la loi dit "le résultat doit être le même que celui qu'un comptable aurait calculé à la main avec telles règles", bah il suffit de le programmer en décimal sans se poser de question.

Mais c'est surtout qu'en calcul financier, on ne calcule pas de projections, de déterminant, on n'inverse pas des matrices ou autres opérations casse-gueule. Sinon, on aurait les mêmes problèmes, même avec de la virgule fixe.

Note qu'en flottant aussi, on décide à l'avance d'une précision fixe (binary32 ou binary64) et d'une règle d'arrondi précise.

Le gros problème ne vient pas seulement de la conversion, il vient du fait qu'à chaque opération il y a une erreur d'arrondi (idéalement sur le dernier bit de la mantisse) et que ces erreurs se propagent et s'amplifient.

L'intérêt de l'arithmétique IEEE-754, c'est que les opérations se comportent comme si le résultat était calculé en précision infini, puis arrondi (converti) en précision de travail.
Du coup, l'arrondi devient une opération mathématique comme une autre qui a une définition formelle précise. On peut donc dire que le résultat mathématique du calcul a*b+c en flottant est :
R(R(a × b) + c)
ou R est l'opération d'arrondi. Les × et + sont les opérations mathématiques sur les nombres réels.

Et je ne parle pas de fonctions mathématiques comme les logarithmes ou les fonctions trigonométriques qui évidemment calculent des approximations.

Là c'est plus compliqué. Arrondir correctement les fonctions élémentaires (renvoyer le flottant qui est l'arrondi du résultat exact) est un problème dur. Aujourd'hui, on commence à savoir faire, mais ce n'est pas encore très répandu. Du coup, même la nouvelle norme IEEE-754 n'oblige pas l'arrondi correct de ces fonctions, mais elle l'encourage juste fortement.

Dans tous les cas, ce n'est pas un problème pour borner les erreurs, vu que n'importe quelle bibliothèque mathématique pas trop pourrie te garantit des bornes d'erreurs relatives sur les résultats.

P.S. le #define de PI est une chose que je ne critiquerais pas par contre dans le code qu'on a vu. Après tout, cela ne dégrade rien, ne pose pas de soucis de lisibilité, et permet de gérer justement des nombre dont la précision peut être plus grande. Ou est le problème ?

Ça montre juste que l'auteur n'a pas compris ce que c'est qu'un flottant, et que c'était une erreur de lui confier la tâche d'écrire le moindre code virgule flottante sans formation préalable. C'est tout.

[TiNitro]

c'est vrai: le copier/coller c'est le MAL

---------- Post added at 13h58 ---------- Previous post was at 13h55 ----------

// special 0x
static const vector<Canard> mesCanards = {rOut, war-p};
for(auto monCaneton = mesCanards.cbegin(); monCaneton < mesCanards.cend(); monCaneton++)
{
monCaneton->Plussoie("C'est vrai!");
}

[rOut]

Tu vas avoir du mal avec "war-p"

[war-p]

c'est vrai: le copier/coller c'est le MAL

---------- Post added at 13h58 ---------- Previous post was at 13h55 ----------

// special 0x
static const vector<Canard> mesCanards = {rOut, war-p};
for(auto monCaneton = mesCanards.cbegin(); monCaneton < mesCanards.cend(); monCaneton++)
{
monCaneton->Plussoie("C'est vrai!");
}

Mon héro! /HS

EDIT : warp marche aussi!

[Møgluglu]

"monCaneton != mesCanards.cend();" et "++monCaneton" vaincront!

Sinon, le tl;dr de mon pavé au dessus c'est : calculer le résultat exact, c'est pas possible. Mais on s'en fout du résultat exact. On veut juste connaître ce que renvoit une comparaison entre les résultats de deux calculs, qui peut renvoyer : oui, non, peut-être.

C'est pas facile dans le cas général, mais c'est tout à fait faisable et il y a plein d'outils pour ça depuis 60 ans. C'est juste qu'à peu près personne ne sait s'en servir parce que ça n'intéresse à peu près personne.

[rOut]

Du coup, l'arrondi devient une opération mathématique comme une autre qui a une définition formelle précise. On peut donc dire que le résultat mathématique du calcul a*b+c en flottant est :
R(R(a × b) + c)
ou R est l'opération d'arrondi. Les × et + sont les opérations mathématiques sur les nombres réels.

Je m'amusais tout à l'heure avec ça, et il se trouve même que a*b = R(R(a)xR(b)), il y a un arrondi à chaque étape, mais bon ça ne change pas grand chose sur le principe.

Exemple, avec x la multiplication mathématique exacte, * la multiplication binary32 de l'ordinateur, R la conversion décimal->binary32:

a    = 1.12345678
R(a) = 1.12345683574676513671875

b    = 1.98765432
R(b) = 1.98765432834625244140625

a*b    = 2.2330439090728759765625
R(a*b) = 2.2330439090728759765625 == a*b

axb    = 2.2330437221002896
R(axb) = 2.233043670654296875 != a*b

R(a)xR(b)    = 2.2330438422822425081903929822146892547607421875
R(R(a)xR(b)) = 2.2330439090728759765625 == a*b

[Møgluglu]

Je supposais que a et b étaient des nombres flottants.

Si ce sont des littéraux décimaux, il y a effectivement une première conversion qui est faite à la compilation.

Tu peux entrer tes flottants en hexadécimal pour éviter la conversion de base :
genre float a = 0x1234abp-2f;

Même problème pour l'affichage, mais tu peux les afficher en hexa.

Ou alors tu utilises les formats decimal64 ou decimal128…

[war-p]

Heu, j'ai une question purement technique pour du C# je suppose que c'est pareil en C++, mais bon.
Voilà, je sais qu'il existe des fonctions qui peuvent attendre genre soit un entier soit un booléen par exemple, (ça fait un truc comme ça : choix1 maFonction(int monNombre), choix2 maFonction(bool monBool)) Quelqu'un saurait déclarer ce genre de chose?

[TiNitro]

"monCaneton != mesCanards.cend();" et "++monCaneton" vaincront!

Pfff pinailleur.

Et d'abord, je maintiens "monCaneton < mesCanards.cend();". Au cas ou je décrémente mon itérateur de plusieurs unités à la fois.
PArce que moi aussi j'aim enbien en rajouter une couche

[rOut]

Je supposais que a et b étaient des nombres flottants.

Si ce sont des littéraux décimaux, il y a effectivement une première conversion qui est faite à la compilation.

Tu peux entrer tes flottants en hexadécimal pour éviter la conversion de base :
genre float a = 0x1234abp-2f;

Même problème pour l'affichage, mais tu peux les afficher en hexa.

Ou alors tu utilises les formats decimal64 ou decimal128…

C'est pas encore standard le type decimal en C/C++

Heu, j'ai une question purement technique pour du C# je suppose que c'est pareil en C++, mais bon.
Voilà, je sais qu'il existe des fonctions qui peuvent attendre genre soit un entier soit un booléen par exemple, (ça fait un truc comme ça : choix1 maFonction(int monNombre), choix2 maFonction(bool monBool)) Quelqu'un saurait déclarer ce genre de chose?

Bah

choix1 maFonction(int monNombre) {
  // blabla...
}
choix2 maFonction(bool monNombre) {
  // blabla...
}

A moins qu'il ne te fasse chier que bool et int c'est pareil mais je ne pense pas. En particulier pas en C#.

[war-p]

Bah le bool et le int, c'était pour l'exemple, en réalité c'est pour des types spéciaux... Mais, faut vraiment réécrire 2 fois la fonction? (C'est pour ça que je demandais en fait, parce que évidemment, seul quelque petites choses diffèrent... Oui, je sais, je suis casse couilles)

[rOut]

Bin oui, mais l'une peut appeler l'autre.
En général si tu utilises deux types différents en paramètres c'est soit que l'implémentation est différente, soit qu'un type peut se convertir facilement en l'autre, et dans ce cas il suffit d'appeler la méthode qui implémente l'algorithme le plus générique.

En C++ après tu as les templates qui te permettent d'écrire une seul fois un algorithme générique qui pourra s'appliquer sur tout type vérifiant un certain nombre de contraintes (par exemple, la STL fourni des algorithmes de tri qui fonctionne sur n'importe quelle classe fournissant un concept d'itérateur - pour faire simple).

En C# l'autre solution qui est en apparence similaire au C++ (sauf que ça n'a rien à voir, mais ça fait un peu pareil), c'est d'utiliser une méthode "generic".
Tu fais comme ça:

choix maFonction<T>(T monNombre) {
  // blabla
}

T pouvant prendre n'importe quel type ensuite (il y a peut être moyen d'ajouter des contraintes, je ne me souviens plus).
Ensuite, pour utiliser la méthode, tu fais soit Objet.maFonction<T>(Nombre), en explicitant le type utilisé soit Objet.maFonction(Nombre), ou il va déterminer tout seul comme un grand à l'aide du type de "Nombre" (je ne sais plus si ça marche en C# mais sans doute).