Re: Standardizes use of empty extents in pure heights and skylines. (issue 7310075)

[Keith OHara]

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.