weird rounding error?
4 vues (au cours des 30 derniers jours)
Afficher commentaires plus anciens
Jason
le 21 Avr 2017
Commenté : Roger Stafford
le 21 Avr 2017
Hello. I'm getting the following odd "error" which I hope is just a display thing but really doesn't seem to be. I'm using R2016a on redhat linux.
>> format long
>> 177.5 - 170.6
ans = 6.900000000000006
>> 177.5 - 170.6 -6.9
ans = 5.329070518200751e-15
>> 1.5 - 0.6
ans = 0.900000000000000
>> 10.5 - 9.6
ans = 0.900000000000000
>> 100.5 - 99.6
ans = 0.900000000000006
>> (100.5 - 99.6) > 0.9
ans = 1
0 commentaires
Réponse acceptée
David Goodmanson
le 21 Avr 2017
Modifié(e) : David Goodmanson
le 21 Avr 2017
Hi Jason, this is just Computer Science 101. Since computers have only so many bits to describe floating point numbers, there are going to be differences like this (not errors), down at the last-bit level. Good that you had enough interest in the details to recognize this effect. See 'help eps'.
In IEEE 754 standard which Matlab uses, 64 bit floating point numbers have 53 bits allotted for the significant figure part. It's worthwhile to go to Wikipedia for a summary of IEEE 754.
1 commentaire
James Tursa
le 21 Avr 2017
E.g., some of the exact decimal conversions involved above:
>> num2strexact(177.5)
ans =
1.775e2
>> num2strexact(177.6)
ans =
1.77599999999999994315658113919198513031005859375e2
>> num2strexact(6.9)
ans =
6.9000000000000003552713678800500929355621337890625
>> num2strexact(177.5 - 170.6 -6.9)
ans =
5.3290705182007513940334320068359375e-15
>> num2strexact(1.5 - 0.6)
ans =
0.90000000000000002220446049250313080847263336181640625
>> num2strexact(10.5 - 9.6)
ans =
0.9000000000000003552713678800500929355621337890625
>> num2strexact(100.5 - 99.6)
ans =
0.900000000000005684341886080801486968994140625
Plus de réponses (2)
Jason
le 21 Avr 2017
2 commentaires
James Tursa
le 21 Avr 2017
This is not "MATLAB" behavior, per se ... it is floating point arithmetic behavior that you would encounter on any machine using binary floating point to represent the numbers. You will run into it with other languages as well.
For calculators, any particular calculator might be using binary floating point with a different number of mantissa bits, or it might be using binary coded decimal. So yes the results would not necessarily be expected to compare to MATLAB.
Roger Stafford
le 21 Avr 2017
@Jason: You should be aware of the fact that what you call “matlab behavior” is not really caused by matlab, but rather by the computer you are using to run matlab. Its floating point numbers are designed to use binary numbers, not decimal numbers, and as such it cannot represent most decimal fractions exactly. In particular it cannot represent your fractions, 99.6, 0.6, 0.9 exactly. (This is apparently due to the inefficiency in constructing electronic ten-state circuits, as opposed to two-state circuits, so you can lay the blame on computer engineers.) However, even on a truly decimal machine if you wanted to test, say, the equality
3/14 + (3/14 + 15/14) == (3/14 + 3/14) + 15/14
it is likely the computer would give “false” as its answer, and thereby violate the associative law of addition. Try it on your favorite decimal calculator. The lesson to be learned here is that one should be very cautious in using the equality test for floating point numbers, since it requires exact equality, and even a one-bit difference in the least bit will fail the test.
David Goodmanson
le 21 Avr 2017
Modifié(e) : David Goodmanson
le 21 Avr 2017
Yes, it's interesting that for some tasks such as addition and subtraction of quantities with a fixed number of decimal digits, a $10 calculator does a better job in a sense than does expensive scientific software. But as you alluded, one is stuck with the rules of the game.
0 commentaires
Voir également
Catégories
En savoir plus sur Discrete Math dans Help Center et File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!