Re: A problem with range objects and floating point numbers

[Oliver Heimlich]

Am 23.09.2014 03:27, schrieb s.jo:
> John W. Eaton wrote
>> On 06/20/2014 04:28 PM, Julien Bect wrote:
>>> Hello all,
>>>
>>> I would like to bring the following bug report to your attention :
>>>
>>> http://savannah.gnu.org/bugs/?42589
>>>
>>> A simple example of the regression described in this report is the
>>> following :
>>>
>>>      octave:1> (9:10) * .1 - 1
>>>      ans =
>>>
>>>         -1.0000e-01    2.7756e-17
>>>
>>> The second element should be 0.
>>>
>>> Rik thinks that this bug might be hard to solve... which is why I'm
>>> bringing this up on this list :)
>>
>> Please see my comments on the bug tracker.
>>
>> jwe
> 
> I have the similar problem with octave 3.8.1 on cygwin.
> See below:
> octave:50> t=[-2:0.1:0]
> t =
> 
>  Columns 1 through 5:
> 
>                     -2                  -1.9                  -1.8            
>      
> -1.7                  -1.6
> 
>  Columns 6 through 10:
> 
>                   -1.5                  -1.4                  -1.3            
>      
> -1.2                  -1.1
> 
>  Columns 11 through 15:
> 
>                     -1                  -0.9                  -0.8            
>      
> -0.7                  -0.6
> 
>  Columns 16 through 20:
> 
>                   -0.5                  -0.4                  -0.3            
>      
> -0.2   -0.0999999999999999
> 
>  Column 21:
> 
>                      0
> 
> Range command is not good with floating-point step only starting from
> negative integer as above.
> 
> I am trying to upgrade octave 3.8.2 to see if this problem is fixed.
> 
> I post it just in case.

The results are perfectly okay. This is how floating point works, see
IEEE 754. Above mentioned bug report also gives some explanation in the
comments.

The “problem” occurs because .1 is not a binary floating point number.
and the approximation
0.1000000000000000055511151231257827021181583404541015625 is used
instead. 10 * 0.1 suffers (or in this case benefits) from rounding.

In the last example with t=[-2:0.1:0] only the numbers -2, -1.5, -1,
-0.5, and 0 have the exact value that is displayed. Column 20
additionally yields a propagation of errors. You can check this with the
bit format:

octave:3> format bit
octave:4> -.1
ans = 1011111110111001100110011001100110011001100110011001100110011010
(this is -0.1000000000000000055511151231257827021181583404541015625)

octave:5> -2 + 19 * .1
ans = 1011111110111001100110011001100110011001100110011001100110010000
(this is -0.09999999999999997779553950749686919152736663818359375)

octave:6> t(20)
ans = 1011111110111001100110011001100110011001100110011001100110010000