Re: A problem with range objects and floating point numbers

[Daniel J Sebald]

On 09/25/2014 01:16 AM, Markus wrote:
> Am 2014-09-25 07:54, schrieb Oliver Heimlich:
> > Am 24.09.2014 20:06, schrieb Daniel J Sebald:
> > > On 09/24/2014 12:29 PM, Oliver Heimlich wrote:

[snip]

> > This is because x/x==1 with any x. I do not have to emphasize that both
> > πs are equal.
> >
> > > octave-cli:3> ((50*pi)/pi) == 50.0
> > > ans = 1
> > > octave-cli:4> ((pi*pi)/pi) == pi
> > > ans = 1
> >
> > Both 50 and the π constant are binary floating point numbers, so the
> > results may be exact. Additionally, the π constant's very last binary
> > digits are zero, so there is some protection against errors. Try the
> > following:
> >
> > octave:1> x = pi + eps * 2;
> > octave:2> x * 50 / 50 == x
> > ans = 0
>
> oh boy
>
> octave:9> 0.1 + 0.2 == 0.3
> ans = 0
> octave:10> 0.1 + 0.2 - 0.2 == 0.1
> ans = 0
> octave:11> fprintf("%.24f == %.24f\n", 0.1 + 0.2, 0.3)
> 0.300000000000000044408921 == 0.299999999999999988897770
>
>
> So, no surprise here.
> You should read this
> http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
>
>
> And for the sake of completeness ....
>
> # Matlab
> > > 0.1 + 0.2 == 0.3
>
> ans =
>
> 0
>
> > > 0.1 + 0.2 -0.2 == 0.1
>
> ans =
>
> 0

OK, true.  I suppose that explains why the range-generating algorithm 
accumulates errors when adding the step size so often.

However, the original algorithm I was pondering is comprised of division.

Given [A:s:B], if

  1) A is integer, and
  2) A/s is integer

then [A:s:B] can be implemented as

  [A/s:1:floor(B/s)] * s

where the range operation is integer-based.

Will that eliminate the accumulation of addition errors that Jo pointed 
out?  Is changing the problem into one of multiplication rather addition 
when possible a good idea?  Or is the problem only manifesting somewhere 
else?

Dan