[Scilab-users] Strange floating point issue below %eps

[antoine monmayrant]

Thanks a lot Bruno!

I knew I had read something like that but could not remember what it was 
called.

Cheers,

Antoine

PS: Samuel, do you think you could close the bug by pointing to this 
"round to even" rule?


Le 19/09/2017 à 11:16, Pinçon Bruno a écrit :
> Le 18/09/2017 à 20:54, Samuel Gougeon a écrit :
>>
>> Now comes the issue:
>> In (A), the relative difference 1/2^53 is too small (< %eps) to be 
>> recorded and to change the number. OK.
>> Since 1 / (2^53 +2) is even smaller than 1 / (2^53), it should nor 
>> make a difference. Yet, it does:
>>
>> --> (2^53 + 2^1) + 1 == (2^53 + 2^1)
>>  ans  =
>>   F
>>
>> How is this possible ??!
>>
>
> Hi all,
>
>    no issue here but simply the round to even rule. Every real number
>   should be approximated by the nearest floating point number but in 
> case of
>   a number exactly between 2 successive floats the one with an even end
>   digit win. You can see this rule as a mean to approximate those 
> ambiguous cases,
>   one in two down and one in two up, but has more subtle features in 
> it such
>   (it is explained in Knuth I).
>
>
>   OK that2^53 + 2^1 is exactly represented
>   (it is a double float number). When computing :
>
>           x = (2^53 + 2^1) + 1
>
>   it is not a float but is exactly at the same distance between the 
> two floats :
>
> 2^53 + 2^1   and 2^53 + 2^2  but this last one ends with a even digit (0)
>   so :
>          fl( (2^53 + 2^1) + 1) = 2^53 + 2^2
>
>   hth
>  Bruno
>
>
>
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.scilab.org/pipermail/users/attachments/20170919/288afb57/attachment.htm>