Hi,
consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. If I evaluate this in VW, I get 1.0 - as expected. However, computing this sum in Java, Python or JS gives 0.9999999999999999. Why are the results different? Does ST handle floats differently, maybe applying another rounding mode? Regards, Steffen _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Define "expected". For example,
0.4d + 0.3d + 0.2d + 0.1d = 1.0d evaluates to 'false'. On 2/13/14 2:23 AM, Steffen Märcker wrote: > Hi, > > consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. If I > evaluate this in VW, I get 1.0 - as expected. However, computing this > sum in Java, Python or JS gives 0.9999999999999999. Why are the results > different? Does ST handle floats differently, maybe applying another > rounding mode? > > Regards, > Steffen > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
(0.4d + 0.3d + 0.2d + 0.1d) printString prints a 1.0d. But when you inspect the result (as bytes) you'll see, that the number is not an exact 1.0. Just the printing function tells you. NEVER EVER check reals on equality (maybe except the 0.0). This is and was a golden rule of programming. Karl -----Ursprüngliche Nachricht----- Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Andres Valloud Gesendet: Donnerstag, 13. Februar 2014 11:32 An: [hidden email] Betreff: Re: [vwnc] Question on floating point arithmetics Define "expected". For example, 0.4d + 0.3d + 0.2d + 0.1d = 1.0d evaluates to 'false'. On 2/13/14 2:23 AM, Steffen Märcker wrote: > Hi, > > consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. If I > evaluate this in VW, I get 1.0 - as expected. However, computing this > sum in Java, Python or JS gives 0.9999999999999999. Why are the > results different? Does ST handle floats differently, maybe applying > another rounding mode? > > Regards, > Steffen > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steffen Märcker
Steffen Märcker wrote Thursday, February 13, 2014 12:24 PM:
> Consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. > If I evaluate this in VW, I get 1.0 - as expected. However, > computing this in Java, Python or JS gives 0.9999999999999999. Please send this to the Java, Python and JS mailing lists :) Sorry, couldn't resist! Steve _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by BREITH Karl-Albert (AREVA)
Indeed, I somehow didn't see the different bytes - although I was starring
at them in the inspector's IEEE view. @_@ Sorry, my fault. Am 13.02.2014, 11:52 Uhr, schrieb BREITH Karl-Albert (AREVA) <[hidden email]>: > > > (0.4d + 0.3d + 0.2d + 0.1d) printString > prints a 1.0d. > But when you inspect the result (as bytes) you'll see, that the number > is not an exact 1.0. > Just the printing function tells you. > > NEVER EVER check reals on equality (maybe except the 0.0). > This is and was a golden rule of programming. > > Karl > > -----Ursprüngliche Nachricht----- > Von: [hidden email] [mailto:[hidden email]] Im > Auftrag von Andres Valloud > Gesendet: Donnerstag, 13. Februar 2014 11:32 > An: [hidden email] > Betreff: Re: [vwnc] Question on floating point arithmetics > > Define "expected". For example, > > 0.4d + 0.3d + 0.2d + 0.1d = 1.0d > > evaluates to 'false'. > > On 2/13/14 2:23 AM, Steffen Märcker wrote: >> Hi, >> >> consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. If I >> evaluate this in VW, I get 1.0 - as expected. However, computing this >> sum in Java, Python or JS gives 0.9999999999999999. Why are the >> results different? Does ST handle floats differently, maybe applying >> another rounding mode? >> >> Regards, >> Steffen >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by BREITH Karl-Albert (AREVA)
Indeed, I somehow didn't see the different bytes - although I was starring
at them in the inspector's IEEE view. @_@ Sorry, my fault. Am 13.02.2014, 11:52 Uhr, schrieb BREITH Karl-Albert (AREVA) <[hidden email]>: > > > (0.4d + 0.3d + 0.2d + 0.1d) printString > prints a 1.0d. > But when you inspect the result (as bytes) you'll see, that the number > is not an exact 1.0. > Just the printing function tells you. > > NEVER EVER check reals on equality (maybe except the 0.0). > This is and was a golden rule of programming. > > Karl > > -----Ursprüngliche Nachricht----- > Von: [hidden email] [mailto:[hidden email]] Im > Auftrag von Andres Valloud > Gesendet: Donnerstag, 13. Februar 2014 11:32 > An: [hidden email] > Betreff: Re: [vwnc] Question on floating point arithmetics > > Define "expected". For example, > > 0.4d + 0.3d + 0.2d + 0.1d = 1.0d > > evaluates to 'false'. > > On 2/13/14 2:23 AM, Steffen Märcker wrote: >> Hi, >> >> consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. If I >> evaluate this in VW, I get 1.0 - as expected. However, computing this >> sum in Java, Python or JS gives 0.9999999999999999. Why are the >> results different? Does ST handle floats differently, maybe applying >> another rounding mode? >> >> Regards, >> Steffen >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steven Kelly
=) You're very welcome!
Am 13.02.2014, 12:14 Uhr, schrieb Steven Kelly <[hidden email]>: > Steffen Märcker wrote Thursday, February 13, 2014 12:24 PM: >> Consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. >> If I evaluate this in VW, I get 1.0 - as expected. However, >> computing this in Java, Python or JS gives 0.9999999999999999. > > Please send this to the Java, Python and JS mailing lists :) > > Sorry, couldn't resist! > Steve > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steven Kelly
Steven Kelly <stevek <at> metacase.com> writes:
> > Steffen Märcker wrote Thursday, February 13, 2014 12:24 PM: > > Consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. > > If I evaluate this in VW, I get 1.0 - as expected. However, > > computing this in Java, Python or JS gives 0.9999999999999999. > > Please send this to the Java, Python and JS mailing lists :) > > Sorry, couldn't resist! > Steve > And Squeak and Pharo too just do like the rest of the world... Why would the rest of the world be so stupid? Here are 3 possible expectations for a decimal printString: 1) every two different Float shall have a different printString representation 2) the printString should be re-interpreted as the same Float 3) the printString should be the shortest decimal that would be re-interpreted as the same Float Requirement 2) is stronger than 1), and 3) is stronger than 2). For a REPL, we at least want 2) but prefer 3) to avoid spurious digits when printing 0.1 Visualworks does not even honour expectation 1), but maybe we don't really eval/print in Visualworks? _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
VA Smalltalk produces 1.0 as the result. All calculators will also give
the answer 1.0. Most of the time, systems that want to present useful answers for floating point calculations will perform the calculation at a higher precision and round the result to fewer decimal places to present that result to the user. The printString method is intended for developers to use to recognize the number. When a developer sees the answer 0.999999999999999 they have to mentally strip off the 9's and add 1 to the number to get the real answer. Most of the time, (I'd say 99.999999% of the time ), this is just a pain and we would rather see the rounded number. This behavior is controlled by the method defaultNumberOfDigits. Change that for Double from 14 to 16 and you'll probably get the effect that you're looking for. You can do that with an override without imposing that change of behavior on all VW users. It's an implementation choice by VW to present an answer that's probably more useful to more people than otherwise. If you do want to see the extra digits, you can change that method or choose to always call printOn:digits: to explicitly request the number of digits. I don't see the problem. David Buck On 2014-02-13 11:14 PM, nicolas cellier wrote: > Steven Kelly <stevek <at> metacase.com> writes: > >> Steffen Märcker wrote Thursday, February 13, 2014 12:24 PM: >>> Consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. >>> If I evaluate this in VW, I get 1.0 - as expected. However, >>> computing this in Java, Python or JS gives 0.9999999999999999. >> Please send this to the Java, Python and JS mailing lists :) >> >> Sorry, couldn't resist! >> Steve >> > > And Squeak and Pharo too just do like the rest of the world... > Why would the rest of the world be so stupid? > Here are 3 possible expectations for a decimal printString: > > 1) every two different Float shall have a different printString representation > 2) the printString should be re-interpreted as the same Float > 3) the printString should be the shortest decimal that would be > re-interpreted as the same Float > > Requirement 2) is stronger than 1), and 3) is stronger than 2). > For a REPL, we at least want 2) but prefer 3) to avoid spurious digits when > printing 0.1 > > Visualworks does not even honour expectation 1), but maybe we don't really > eval/print in Visualworks? > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Nicolas Cellier
That is what I expect from storeString
(method comment "Answer a String representation of the receiver from which the receiver can be reconstructed.") printString's method comment only states "Answer a String whose characters are a description of the receiver." For supported customers there is resolution 100312, which fixes storeString so that it fulfills expectation 2). Ralf Am 14.02.2014 05:14, schrieb nicolas cellier: > Steven Kelly <stevek <at> metacase.com> writes: > >> >> Steffen Märcker wrote Thursday, February 13, 2014 12:24 PM: >>> Consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. >>> If I evaluate this in VW, I get 1.0 - as expected. However, >>> computing this in Java, Python or JS gives 0.9999999999999999. >> >> Please send this to the Java, Python and JS mailing lists :) >> >> Sorry, couldn't resist! >> Steve >> > > > And Squeak and Pharo too just do like the rest of the world... > Why would the rest of the world be so stupid? > Here are 3 possible expectations for a decimal printString: > > 1) every two different Float shall have a different printString representation > 2) the printString should be re-interpreted as the same Float > 3) the printString should be the shortest decimal that would be > re-interpreted as the same Float > > Requirement 2) is stronger than 1), and 3) is stronger than 2). > For a REPL, we at least want 2) but prefer 3) to avoid spurious digits when > printing 0.1 > > Visualworks does not even honour expectation 1), but maybe we don't really > eval/print in Visualworks? > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by davidbuck
> I don't see the problem.
Except of course the printing algorithm has bugs that would prevent round trip conversion to and from strings. In any case, interpretation of literals also has bugs so when you write 0.1234643567357623 it's not certain you will get the floating point number closest to that decimal expression. With all of that said, it's not reasonable to expect 0.4 + 0.3 + 0.2 + 0.1 = 1.0 or even that the sum might print as expected for the above or other similar expressions. It's the same as some other discussion we already had where there was the expectation that 17 / 20 = 0.85 had to be true. In binary floating point arithmetic, it is *impossible* to have equality with 17 / 20. Floating point arithmetic doesn't work that way. On 2/14/14 1:16 AM, David Buck wrote: > VA Smalltalk produces 1.0 as the result. All calculators will also give > the answer 1.0. Most of the time, systems that want to present useful > answers for floating point calculations will perform the calculation at > a higher precision and round the result to fewer decimal places to > present that result to the user. > > The printString method is intended for developers to use to recognize > the number. When a developer sees the answer 0.999999999999999 they > have to mentally strip off the 9's and add 1 to the number to get the > real answer. Most of the time, (I'd say 99.999999% of the time ), this > is just a pain and we would rather see the rounded number. > > This behavior is controlled by the method defaultNumberOfDigits. Change > that for Double from 14 to 16 and you'll probably get the effect that > you're looking for. You can do that with an override without imposing > that change of behavior on all VW users. It's an implementation choice > by VW to present an answer that's probably more useful to more people > than otherwise. If you do want to see the extra digits, you can change > that method or choose to always call printOn:digits: to explicitly > request the number of digits. I don't see the problem. > > David Buck > > On 2014-02-13 11:14 PM, nicolas cellier wrote: >> Steven Kelly <stevek <at> metacase.com> writes: >> >>> Steffen Märcker wrote Thursday, February 13, 2014 12:24 PM: >>>> Consider the following expression: 0.4d + 0.3d + 0.2d + 0.1d. >>>> If I evaluate this in VW, I get 1.0 - as expected. However, >>>> computing this in Java, Python or JS gives 0.9999999999999999. >>> Please send this to the Java, Python and JS mailing lists :) >>> >>> Sorry, couldn't resist! >>> Steve >>> >> >> And Squeak and Pharo too just do like the rest of the world... >> Why would the rest of the world be so stupid? >> Here are 3 possible expectations for a decimal printString: >> >> 1) every two different Float shall have a different printString >> representation >> 2) the printString should be re-interpreted as the same Float >> 3) the printString should be the shortest decimal that would be >> re-interpreted as the same Float >> >> Requirement 2) is stronger than 1), and 3) is stronger than 2). >> For a REPL, we at least want 2) but prefer 3) to avoid spurious digits >> when >> printing 0.1 >> >> Visualworks does not even honour expectation 1), but maybe we don't >> really >> eval/print in Visualworks? >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |