Review Request: KColorSpace::KHCY::KHCY(const & QColor) constructor floating point precision error
hans_meine at gmx.net
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..
More information about the kde-core-devel