Date: Mon, 15 Jan 2018 20:41:13 +0300 From: Yuri Pankov <yuripv@icloud.com> To: Mehmet Erol Sanliturk <m.e.sanliturk@gmail.com> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: inconsistent for() and while() behavior when using floating point Message-ID: <bc82cf03-22c9-9e83-49e1-58d072bb83c8@icloud.com> In-Reply-To: <CAOgwaMuBnW%2BzY=JUFqKNAUrVtOxmjn1F_usvpYp05Gcg7EF-zw@mail.gmail.com> References: <6c423dbf-cd85-3c93-41e4-3362c06dfbb7@icloud.com> <CAOgwaMuBnW%2BzY=JUFqKNAUrVtOxmjn1F_usvpYp05Gcg7EF-zw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@icloud.com > <mailto:yuripv@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bc82cf03-22c9-9e83-49e1-58d072bb83c8>