Subject: Re: [boost] floating point FUD
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2010-01-24 06:02:30
Thomas Klimpel wrote:
> But I never found a bug in such code that would have been
> a fundamental problem with floating point, but always just
> the "usual" floating point traps I keep overlooking by mistake.
> Now somebody will probably suggest that I should at least
> document the "usual" floating point traps then. So I created
> the attached small test program showing the "usual" floating
> point traps I could still remember having overlooked at least once.
It seems I wasn't explicit enough: The function "buggy_function" is intended to show the 'different' types of "usual" floating point traps that 'hit me' at least once. Some of them are not subtle floating point behavior, but real bugs (with simple obvious fixes) caused by the semantics of C++. However, it's true that they are often difficult to trigger and difficult to spot. So I guess I should have at least included the compiler warnings from MSVC9, as they contain helpful indications of what goes actually wrong:
> I created a new project with MSVC9.
> The debug version compiles with warnings for the things that go badly wrong and executes with output:
.\test_fp.cpp(25) : warning C4146: unary minus operator applied to unsigned type, result still unsigned
.\test_fp.cpp(26) : warning C4244: 'argument' : conversion from 'double' to 'int', possible loss of data
.\test_fp.cpp(27) : warning C4244: 'argument' : conversion from 'double' to 'int', possible loss of data
Here are the corresponding lines of the function "buggy_function":
24: double t = -delta*sorted.size();
25: double tt = -sorted.size()*delta;
26: bool t_tt = (abs(t-tt) < eps);
27: bool abs_t = (abs(t) == -t);
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk