octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A problem with range objects and floating point numbers


From: Daniel J Sebald
Subject: Re: A problem with range objects and floating point numbers
Date: Wed, 24 Sep 2014 10:47:54 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

On 09/23/2014 01:12 AM, Oliver Heimlich wrote:
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

Thank you for the explanation Oliver.

Would there be any utility to attempting to "integerize" the range, if possible, and thereby eliminate the accumulation of errors? For example, [-2:0.1:0] is equivalent to [-20:1:0]*.1, so if the limits turn out to be factorable, then internally the range could be represented slightly different than what the user types.

  scale = 1.0;
...
  if (range.limits_are_factorable ())
    {
      start /= step;
      scale = step;
    }
...
  ridx.xelem (i) = (start + i*step)*scale;

To be factorable doesn't necessarily require that the floating point step size be an exact number system equivalent, i.e., that .1 equal exactly 1/10. It just requires the machine arithmetic to be as expected when producing an operation result, i.e.,

octave-cli:1> rem(-2,.1) == 0
ans =  1
octave-cli:2> rem(0,.1) == 0
ans =  1
octave-cli:3> [-20:1:0]*.1
ans =

 Columns 1 through 5:

  -2.00000  -1.90000  -1.80000  -1.70000  -1.60000

 Columns 6 through 10:

  -1.50000  -1.40000  -1.30000  -1.20000  -1.10000

 Columns 11 through 15:

  -1.00000  -0.90000  -0.80000  -0.70000  -0.60000

 Columns 16 through 20:

  -0.50000  -0.40000  -0.30000  -0.20000  -0.10000

 Column 21:

   0.00000


Jo, what do you get for the above scripts?

Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]