Re: A problem with range objects and floating point numbers

[Oliver Heimlich]

Hello Jo, hello Dan,

Am 23.09.2014 17:28, schrieb s.jo:
> %%
> % setup
> fp_start=-2;
> fp_end=1;
> fp_step=0.1;
> fp_num=fix(abs(fp_end-fp_start)/fp_step)+1;
> % range operator (floating-point)
> t1=(fp_start:fp_step:fp_end);
> % linspace function
> t2=linspace(fp_start,fp_end,fp_num);
> % compare
> format long e
> [t1' t2']
…
> 
> %% results:
> 
> ans =
> 
>   -2.00000000000000e+00  -2.00000000000000e+00
>   -1.90000000000000e+00  -1.90000000000000e+00
>   -1.80000000000000e+00  -1.80000000000000e+00
>   -1.70000000000000e+00  -1.70000000000000e+00
>   -1.60000000000000e+00  -1.60000000000000e+00
>   -1.50000000000000e+00  -1.50000000000000e+00
>   -1.40000000000000e+00  -1.40000000000000e+00
>   -1.30000000000000e+00  -1.30000000000000e+00
>   -1.20000000000000e+00  -1.20000000000000e+00
>   -1.10000000000000e+00  -1.10000000000000e+00
>   -1.00000000000000e+00  -1.00000000000000e+00
>   -9.00000000000000e-01  -9.00000000000000e-01
>   -8.00000000000000e-01  -8.00000000000000e-01
>   -7.00000000000000e-01  -7.00000000000000e-01
>   -6.00000000000000e-01  -6.00000000000000e-01
>   -5.00000000000000e-01  -5.00000000000000e-01
>   -4.00000000000000e-01  -4.00000000000000e-01
>   -3.00000000000000e-01  -3.00000000000000e-01
>   -2.00000000000000e-01  -2.00000000000000e-01
>   -9.99999999999999e-02  -1.00000000000000e-01
>    1.11022302462516e-16   0.00000000000000e+00
>    1.00000000000000e-01   1.00000000000000e-01
>    2.00000000000000e-01   2.00000000000000e-01
>    3.00000000000000e-01   3.00000000000000e-01
>    4.00000000000000e-01   4.00000000000000e-01
>    5.00000000000000e-01   5.00000000000000e-01
>    6.00000000000000e-01   6.00000000000000e-01
>    7.00000000000000e-01   7.00000000000000e-01
>    8.00000000000000e-01   8.00000000000000e-01
>    9.00000000000000e-01   9.00000000000000e-01
>    1.00000000000000e+00   1.00000000000000e+00
…
> 
> Thus, the implementation of the floating-point case colon operator should be
> changed to use the linspace function or equivalent, I guess.
> 
> I agree that it is not a bug of colon operator. It is a nature behavior.
…
> 
> Mathlab does not show such behavior at least with 'format long e'. I need to
> check the raw bit format.
> I guess that they use linspace or similar in colon operator.
> 
> -- jo.

You would have to do some decimal(!) arithmetic of the user's input(!)
to be able to convert the colon operator into an equivalent linspace
function call, as proposed by Daniel (see below).

Remember, that the input “0.1” actually takes a different value and you
tell the colon operator to create a vector of values from -2 to 1 with a
distance of 0.1000…05551115123… each. It is no surprise that you do not
exactly hit some of your expected values.

On the other side you give exact integer parameters to the linspace
function. It is no wonder that the linspace function can produce most
accurate results.

Am 24.09.2014 17:47, schrieb Daniel J Sebald:
> 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.

You try to make the colon operator context sensitive and require the use
of decimal arithmetic. This is not a good idea. It would be a very
special behaviour that does not conform IEEE 754 and what an experienced
user would expect. It would create even more unpredictable cases.

I suggest, that you (or any other user) prefers the linspace function
over the colon operator and use the colon operator carefully with the
binary floating point context in mind. For example instead of 0.1 you
can use the numbers 0.125 (=2^-3) or 0.09375 (=2^-4 + 2^-5), which will
produce far less representational errors.

Am 23.09.2014 17:28, schrieb s.jo:
> But, people does not want to see floating-point number's weird
behaviors in
> their application.
> People usually expect the equally spaced numbers when they use colon
> operators.

If people use floating-point numbers (and algorithms) they should know
what they do. Otherwise they could not reasonably trust the results of
their computations.

The numbers are equally spaced within the accuracy of the floating point
context.

IMHO these problems would be much less a surprise to many people if they
could see the exact value of their intermediate results by default
(which would also spam the user's console a lot) instead of a rounded
decimal number like -1.9, -1.8, and so on.