Boost C++ Libraries: Ticket #13011: BOOST_TEST broken with floating point relational operators

nigels.com@… — Sat, 06 May 2017 00:19:49 GMT

Seems be due to BOOST_TEST handling of floating point comparison.

http://www.boost.org/doc/libs/1_64_0/libs/test/doc/html/boost_test/testing_tools/extended_comparison/floating_point/floating_points_comparison_theory.html

This passes, for example:

#define BOOST_TEST_MODULE test
#include <boost/test/included/unit_test.hpp>
BOOST_AUTO_TEST_CASE(Foo)
{
    BOOST_TEST(0.001 < 0.002);
}

chris42f@… — Sat, 06 May 2017 00:39:45 GMT

Right, thanks for digging. Honestly I didn't expect floating point comparison magic in BOOST_TEST by default, and was expecting to do my own epsilon testing.

It's unfortunate that the default behavior fails some obvious desired properties at 0.0 - which as the additive identity is arguably the most commonly encountered value out of the entire floating point range.

I'll admit that in the real use case, I was trying to do my own epsilon testing with a known absolute tolerance specific to the problem - something like

BOOST_TEST(fabs(a-b) < 1e-16)

which fails when a happens to be equal to b. Overall, I'm not thrilled that boost tries to completely hide the problems of floating point comparison from users.

For this case, it sounds like a solution with the current API is to use the obviously naive expression

BOOST_TEST(a == b)

nigels.com@… — Sat, 06 May 2017 02:46:22 GMT

Yes, I agree that the principle of least-surprise ought to apply to BOOST_TEST.

Perhaps we ought to cast to bool as a matter of best practice.

BOOST_TEST( bool(fabs(a-b) < 1e-16) )

anonymous — Sat, 06 May 2017 09:18:28 GMT

Using the bool cast as a matter of course would be terribly unfortunate as it defeats the automatic expression splitting and enhanced error reporting, which is really the whole point of the new BOOST_TEST interface.

nigels.com@… — Sat, 06 May 2017 11:47:31 GMT

My opinion is that the tolerancing built into BOOST_TEST ought to be opt-in.

I'll give it another look the next time I'm adding unit testing, but my initial impression is that I'd rather be explicit about epsilon testing, and be a bit less concerned about the precise type to use for the tolerance value. (Ordinarily I'd expect the usual type promotion rules to apply)

owner, status changed

Raffi Enficiaud — Mon, 15 May 2017 10:11:38 GMT

owner changed from Gennadiy Rozental to Raffi Enficiaud
status new → assigned

milestone changed

Raffi Enficiaud — Fri, 23 Jun 2017 16:31:33 GMT

milestone To Be Determined → Boost 1.65.0

Raffi Enficiaud — Tue, 27 Jun 2017 18:57:43 GMT

Fixed in topic/13011-floating-point-relational-operators

status changed; resolution set

Raffi Enficiaud — Sun, 16 Jul 2017 08:45:26 GMT

status assigned → closed
resolution → fixed

In master, rev 3ddb0e0d29e8ebfe4ba20921a3d366f7b5b837b2