Re: A problem with range objects and floating point numbers

[Daniel J Sebald]

On 09/24/2014 12:29 PM, Oliver Heimlich wrote:
> Hello Jo, hello Dan,

> 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.

That's true, but for binary numbers.  My point was that no matter the 
number representation system, the underlying arithmatic logic unit (ALU) 
should have mathematical consistency.  That is, if the ALU carries out 
an operation, the result should be the equivalent of what is expected in 
mathematics, number representation aside.  I'm wondering if there is 
consistency in hardware architecture.  It may not matter that "0.1" 
(which actually equals 0.10000000000xxx) doesn't equal 1/10, so long as 
the following is true:

octave-cli:1> rem(-2,.1) == 0
ans =  1
octave-cli:2> rem(0,.1) == 0
ans =  1

Try it with some numbers that we know can be represented exactly with 
base 10 or base 2:

octave-cli:2> (pi/pi) == 1.0
ans =  1
octave-cli:3> ((50*pi)/pi) == 50.0
ans =  1
octave-cli:4> ((pi*pi)/pi) == pi
ans =  1

Dan