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
>

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

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

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

> 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

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

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

> 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