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
Looking at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217149
noticed that it isn't a seq(1) problem per se, rather for() and
while() loops behaving inconsistently while using floating point, i.e.:
for (i = 1; i <= 2.00; i += 0.1)
for (i = 1; i <= 2; i += 0.2)
would correctly end with 2:
$ cc -v
FreeBSD clang version 6.0.0 (branches/release_60 321788) (based on
Thread model: posix
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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"