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

Hans Meine hans_meine at
Wed Jun 24 09:52:28 BST 2009

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).  Many of us fell in that trap at 
least once.  (It really looks ridiculous in actual code.)

AFAICS, with zero this will not happen, because of the floating point 
(mantissa truncation will not make it zero).

> 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..

Best greetings,

More information about the kde-core-devel mailing list