CS-212: == sur les doubles et autres

Bonjour,

j'ai un peu de mal à comprendre certains éléments de correction de week03.

Notamment, j'ai les questions suivantes :

- '== sur les double' : j'ai bien conscience que comparer des double est une tâche complexe, mais en soi on ne fait qu'écrire des entiers (0 et 1, en l'occurence) qui sont en soi représentables avec précision absolue sur des doubles (en tant que 1.0e0 et 0.0e0, respectivement) et sur lesquels on ne fait aucun calcul, donc rendus tels quels. Je n'ai donc en tant que programmeur aucun scrupule à les comparer avec ==, et ce en pleine connaissance des problèmes que cela pose dans le cas général. Ai-je tort ? On pourrait en soi argumenter que rien n'empêche la spécification du programme de changer les valeurs 0 et 1 par des réels non représentables, mais même dans ce cas la comparaison inter-doubles devrait tenir la route. Puisqu'aucun calcul n'est fait, on ne peut pas se plaindre des erreurs de précision sur les opérations doubles.

(ex :

double pi = M_PI;

pi == 3.14159265358979323846; //est vrai ! pas de calcul -> pas de problème.

MAIS :

double pi = M_PI + 0.5;

pi - 0.5 == 3.14159265358979323846;

//est faux ! enfin, ça dépend du compilateur/de son niveau d'optimisation... mais cela ne nous concerne pas)

- d'autre part, 'gestion de la diagonale' est assez obscur. Devions-nous vérifier que la diagonale est plus petite que les côtés ? C'était explicitement marqué dans le code de laisser tel quel.

- 'réutilisation de yc' : je n'ai pas compris cette ligne, pourriez-vous préciser ?

Merci beaucoup d'avance !

Mathis Randl

Re: == sur les doubles et autres

by Deleted user - Thursday, 2 April 2020, 12:41 PM

Bonjour,

== sur les double

Je comprends tout à fait votre argument. Néanmoins, comme vous l'avez appris en ICC, les ordinateurs ont des limites physiques lorsqu'il s'agit de représenter de l'information, des nombres à virgule flottante dans le cas présent. En tant que programmeur, vous devez garder cela à l'esprit lorsque vous écrivez du code qui manipule de tels nombres. Ce n'est peut-être pas le cas ici, mais vos programmes peuvent avoir des comportements inattendus si vous ne prêtez pas attention à ce genre de détails (importants). Il est considéré être une bonne pratique que d'utiliser un epsilon pour comparer des réels. Un point bonus a donc été introduit à cet égard dans la grille d'évaluation. Ne pas obtenir ce point n'était pas une sanction ;) .

gestion de la diagonale

L'information dans le code indiquant qu'on part du principe que la diagonale peut être plus grande que l'image n'était pas une consigne, mais un commentaire laissé par le "mauvais" programmeur du code fourni pour ce devoir. Vous deviez donc gérer la cohérence de la lecture de la diagonale. Pour ce faire, la lecture de la diagonale devait se faire après la hauteur et la largeur de l'image de manière à connaître sa valeur limite et cette limite devait être ensuite utilisée pour contrôler la lecture.

réutilisation de yc

Dans la fonction diamond, la variable yc devait être réutilisée dans la condition d'arrêt de la boucle afin d'éviter la duplication de code de myIm.height.

Re: == sur les doubles et autres

by Fouad Mahmoud - Thursday, 2 April 2020, 2:02 PM

Ah, puisque la partie == double est un bonus, le rendu est-il bien note sur 39 points et non pas 40?

Re: == sur les doubles et autres

by Jean-Cédric Chappelier - Thursday, 2 April 2020, 2:43 PM

j'ai finalement intégré cela comme un point non bonus pour tomber sur 40 tout rond et aussi parce que c'était assez facile à trouver avec les options du compilateur (-Wfloat-equal) et que 33% de la classe l'a trouvé. Au final, bonus ou pas, cela fait 1 point sur 39 coef 5% soit 1.28 millième (!) de la note finale. Autant dire : rien.

Re: == sur les doubles et autres

by Jean-Cédric Chappelier - Thursday, 2 April 2020, 2:46 PM

juste pour compléter la réponse de Yassin (merci !) :

1. si, ici les double sont modifiés : via le filtre. Et en effet après quelques filtres, les == ne fonctionnent effectivement plus dans certains cas ;
3. c'est plutôt le myIm.height/2 dans le for de la ligne 58.