# Question on floating point arithmetics

11 messages
Open this post in threaded view
|

## Question on floating point arithmetics

 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
Open this post in threaded view
|

## Re: 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
Open this post in threaded view
|

## Re: Question on floating point arithmetics

 (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
Open this post in threaded view
|

## Re: Question on floating point arithmetics

 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
Open this post in threaded view
|

## Re: Question on floating point arithmetics

 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
Open this post in threaded view
|

## Re: Question on floating point arithmetics

 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
Open this post in threaded view
|

## Re: Question on floating point arithmetics

 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
Open this post in threaded view
|

## Re: Question on floating point arithmetics

 In reply to this post by Steven Kelly Steven Kelly 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
Open this post in threaded view
|

## Re: Question on floating point arithmetics

 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 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