On Mon, Jan 15, 2018 at 08:38:15PM +0300, Mehmet Erol Sanliturk: > > > On Mon, Jan 15, 2018 at 5:38 PM, Yuri Pankov <yuripv_at_icloud.com > <mailto:yuripv_at_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.Received on Mon Jan 15 2018 - 17:41:59 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC