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

[Samuel Gougeon]

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




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