On Mon, Jan 15, 2018 at 08:38:15PM +0300, Mehmet Erol Sanliturk:



On Mon, Jan 15, 2018 at 5:38 PM, Yuri Pankov <yur...@icloud.com <mailto:yur...@icloud.com>> wrote:

    Hi,

    Looking at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217149
    <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" .

Indeed, exactly as I did in a patch for that PR.

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 .

Thanks to all replies, I now clearly see the problem.
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to