[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Standardizes use of empty extents in pure heights and skylines. (iss
From: |
Keith OHara |
Subject: |
Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075) |
Date: |
Wed, 13 Mar 2013 11:46:59 -0700 |
User-agent: |
Opera Mail/12.14 (Win32) |
On Wed, 13 Mar 2013 02:44:33 -0700, <address@hidden> wrote:
If left and right have equal values to start with, C++ is still not
required to have left and right receive the same value after
left = left*factor + offset;
right = right*factor + offset;
The C standard requires the variables to be equal after assignment.
C99 5.4.2.2: "Except for assignment and cast (which remove all extra range and
precision), the values of operations with floating operands [...] are evaluated to a
format whose range and precision may be greater than required by the type."
GCC had bug 323, failing to convert to storage formats when required by the standard.
That seems to be fixed with about version 4.5
<http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html>
For a long time it was good to have guard digits, letting round-off affect bits
less-significant than those stored. When memory was expensive we didn't want
to store garbage bits affected by round-off.
With or without guard digits, we need to be careful with /comparison/ between
floating point values, because different computation paths can round off
differently, even if we might expect them to lead to the same result. (Guard
digits reduce the frequency of differences in round-off in stored values, but
then we depend on subtle points of the C99 standard to communicate with the
compiler about when computations are converted to the stored format.)
That's totally sick. It may be worth using GCC compiler options to
disallow extended precision for intermediate results and/or the choice
to store intermediates with less than full precision and try to retain
some kind of deterministic behavior that way.
https://codereview.appspot.com/7310075/
It looks like the relevant compiler options are still buggy before GCC version
4.5
We were only /speculating/ what problems could arise, in an attempt to review the code
for possible problems with "numerical inaccuracies" that the old code was
trying to avoid. We found no potential problems in this code.