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

[antoine monmayrant]

Just digging a bit further in julia:

println("2.0^53+2.0^1   : $(bits(2.0^53+2.0^1))")
println("2.0^53+2.0^1+1 : $(bits(2.0^53+2.0^1+1))")
println("")
println("2.0^53+2.0^2   : $(bits(2.0^53+2.0^2))")
println("2.0^53+2.0^2+1 : $(bits(2.0^53+2.0^2+1))")

gives:

2.0^53+2.0^1   : 
0100001101000000000000000000000000000000000000000000000000000001
2.0^53+2.0^1+1 : 
0100001101000000000000000000000000000000000000000000000000000010

2.0^53+2.0^2   : 
0100001101000000000000000000000000000000000000000000000000000010
2.0^53+2.0^2+1 : 
0100001101000000000000000000000000000000000000000000000000000010

So the first two are different while the last two are bit identical.

I anyone can point to the specific bit in IEEE spec for this, I'll be happy!


Antoine

Le 19/09/2017 à 08:58, antoine monmayrant a écrit :
>
> Houps, my bad, julia does exactly the same when using Float64, not Int64:
>
>
> println((2.0^53 + 2.0^2) + 1.0 == (2.0^53 + 2.0^2))
>
> true
>
> println((2.0^53 + 2.0^1) + 1.0 == (2.0^53 + 2.0^1))
>
> false
>
>
> It has to be some normal IEEE thing but I did not manage to find the 
> proper reference for it.
>
>
> Antoine
>
>
> Le 18/09/2017 à 20:54, Samuel Gougeon a écrit :
>>
>> Dear co-Scilabers,
>>
>> I met a strange Scilab's bug this week-end. But today, i tried with 
>> Octave, Matlab2016 and R, and i found the same strange behavior. So, 
>> either i am missing something, or the bug affects all these languages 
>> in the same way. It is reported @ http://bugzilla.scilab.org/15276
>>
>> In a few words, here it is:
>>
>> The mantissa of any decimal number is recorded on 53 bits (numbered 
>> #0 to #52) + 1 bit for the sign.
>> This relative absolute accuracy sets the value of the epsilon-machine :
>> --> %eps == 2^0 / 2^52
>>  ans  =
>>   T
>> From here, it comes, as expected:
>>
>> --> 2^52 + 1 == 2^52
>>  ans  =
>>   F
>>
>> --> 2^53 - 1 == 2^53
>>  ans  =
>>   F
>>
>> --> 2^53 + 1 == 2^53   // (A)
>>  ans  =
>>   T
>>
>> 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 ??!
>> But this occurs only when THIS bit #0 is set. For higher bits 
>> (hebelow the #1 one), we get back to the expected behavior:
>> --> (2^53 + 2^2) + 1 == (2^53 + 2^2)
>>  ans  =
>>   T
>>
>> So, when the bit #0 is set and we add a value on the bit "#-1", the 
>> language somewhat behaves as if there was a "withholding" value on 
>> the bit #0, and seems to toogle it.
>> Is is a part of any IEEE floating point convention, or am i missing 
>> anything, or is it a true bug?
>> Again, R, Octave and Matlab behave exactly in the same way...
>>
>> Looking forward to reading your thoughts,
>>
>> Samuel
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.scilab.org
>> http://lists.scilab.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> 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/57c49b06/attachment.htm>