Il n'y a pas de bug, tu compares des données de deux types différent, float vs double.
Change la ligne pour passer ton littéral exprimant un double en littéral exprimant un flottant... et le test d'égalité sera vrai.
if(a!=(float)1.26783)printf("Comprends pas");
Si tu veux t'éloigner (un peu seulement) de la technique, laisse tomber le langage C, passe à Python3, où les nombres flottants sont tous en double du C, où 1/2 donnera 0.5. Mais tu auras toujours des problèmes de représentation à un moment donné, à part rester en calcul symbolique, dès que tu passe en numérique, ça coince. Par exemple, dès que tu commences à calculer avec des 1/3, en décimal ça coince.
Decimal Representation: 1.26783
Binary Representation: 00111111101000100100100001000001
Hexadecimal Representation: 0x3fa24841
After casting to double precision: 1.2678300142288208
Et sur la question de la perte en temps de calcul, oui ça serait significatif, dans certains domaines ce sont des milliards d'opérations, ça peut mouliner pendant des jours, tu ne peux pas te permettre d'être 10x ou 100x plus lent.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Un peu de lecture
Posté par lolop (site web personnel) . En réponse au message Euh... comment dire... C'est bizarre.. Évalué à 2.
Il n'y a pas de bug, tu compares des données de deux types différent,
floatvsdouble.Change la ligne pour passer ton littéral exprimant un double en littéral exprimant un flottant... et le test d'égalité sera vrai.
Si tu veux t'éloigner (un peu seulement) de la technique, laisse tomber le langage C, passe à Python3, où les nombres flottants sont tous en
doubledu C, où 1/2 donnera 0.5. Mais tu auras toujours des problèmes de représentation à un moment donné, à part rester en calcul symbolique, dès que tu passe en numérique, ça coince. Par exemple, dès que tu commences à calculer avec des 1/3, en décimal ça coince.Un outil pratique: http://www.h-schmidt.net/FloatConverter/IEEE754.html
Decimal Representation:
1.26783Binary Representation: 00111111101000100100100001000001
Hexadecimal Representation:
0x3fa24841After casting to double precision:
1.2678300142288208Et sur la question de la perte en temps de calcul, oui ça serait significatif, dans certains domaines ce sont des milliards d'opérations, ça peut mouliner pendant des jours, tu ne peux pas te permettre d'être 10x ou 100x plus lent.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN