Review Request: KColorSpace::KHCY::KHCY(const & QColor) constructor floating point precision error

[Oswald Buddenhagen]

On Wed, Jun 24, 2009 at 10:52:28AM +0200, Hans Meine wrote:
> On Wednesday 24 June 2009 00:38:31 Oswald Buddenhagen wrote:
> > On Tue, Jun 23, 2009 at 04:59:12PM -0400, Michael Pyne wrote:
> > > against 0.0 (which is really the only equality comparison you can do
> > > on floating point since it is exact and so are its conversions to
> > > different forms).
> >
> > all small integers (i think +/- 2^23 for single precision) can be
> > represented exactly.
> 
> Yes, but a value which is != 42 in one moment might become == 42 just one LOC 
> below (due to extra precision truncation).
> 
yes

> AFAICS, with zero this will not happen, because of the floating point 
> (mantissa truncation will not make it zero).
> 
sounds somewhat plausible, but i cannot come up with an actual case how
that might happen ... it's too late today. :}

> > and fwiw, ((a == b) == ((a - b) == 0.0)) in any case.
> 
> Unfortunately, such a statement could become false if there is an extra 
> statement inserted after the (a == b) which causes only one of the two 
> variables to be put on the stack (and thus truncated).  That sounds unlikely, 
> but may give you a really evil bug when it happens somehow..
> 
yes, very unlikely, as comparision is just a subtraction which does not
store the result, i.e., the register set up is exactly the same up to
the key instruction - barring arbitrary compiler weirdness.

btw, this 80-bit x86 fpu anomaly can be forced away by putting the
compiler into strict ieee-754 mode (at a non-trivial performance cost,
unless everything is done with sse anyway).