Re: inconsistent for() and while() behavior when using floating point

On Mon, Jan 15, 2018 at 5:38 PM, Yuri Pankov <yuripv_at_icloud.com> wrote:

> Hi,
>
> Looking at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217149, I
> noticed that it isn't a seq(1) problem per se, rather for() and while()
> loops behaving inconsistently while using floating point, i.e.:
>
>         double i;
>
>         for (i = 1; i <= 2.00; i += 0.1)
>                 printf("%g\n", i);
>
> would produce:
>
>         1
>         ...
>         1.9
>
> but:
>
>         double i;
>
>         for (i = 1; i <= 2; i += 0.2)
>                 printf("%g\n", i);
>
> would correctly end with 2:
>
>         1
>         ...
>         2
>
> $ cc -v
> FreeBSD clang version 6.0.0 (branches/release_60 321788) (based on LLVM
> 6.0.0)
> Target: x86_64-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
>
> though gcc 4.4.4 on illumos behaves the same.
>
> Is this a known problem with loops and floating point numbers?
> _______________________________________________
>



When you perform floating point computations , it may be useful to remember
that , the last bits of floating point numbers may be considered to be
"noise" .
For that reason , the same "for" or "while" loops may behave differently in
different times and places .

To make floating point related loops more deterministic , the useful steps
may be to compute "step size" and "number of steps" , and use integer
variables for counting loop steps with multiplication of "loop counter"
and "step size" during loop steps :  For floating point loop counter T =
"integer loop counter" * "step size" .
A statement  like  T = T + "step size" will/may produce wrong results if
number of steps is sufficiently large .


Computer arithmetic and theoretical arithmetic are not the same .
For example , addition is not associative in computer arithmetic : a + ( b
+ c ) is not always equal to ( a + b ) + c .



Mehmet Erol Sanliturk