[Boost.UTF] Strange (failed) result on comparing floats
Hi, I'm checking some data of consistence using boost's unit test framework (1.42): BOOST_CHECK_CLOSE( *v[1].y.max, -43.0e-3, std::numeric_limits<double>::epsilon() ); which fails with: difference{1.6137e-14%} between *v[1].y.max{-0.043000000000000003} and -43.0e-3{-0.042999999999999997} exceeds 2.2204460492503131e-16% where v is a std::vector,y a struct and max a boost::optional<double>. The data where parsed by boost.spirit. This is the only failed test case from 16 parsed doubles. What's gone wrong here? Do I miss something? Thanks, Olaf
AMDG Olaf Peter wrote:
I'm checking some data of consistence using boost's unit test framework (1.42):
BOOST_CHECK_CLOSE( *v[1].y.max, -43.0e-3, std::numeric_limits<double>::epsilon() );
which fails with:
difference{1.6137e-14%} between *v[1].y.max{-0.043000000000000003} and -43.0e-3{-0.042999999999999997} exceeds 2.2204460492503131e-16%
where v is a std::vector,y a struct and max a boost::optional<double>. The data where parsed by boost.spirit. This is the only failed test case from 16 parsed doubles. What's gone wrong here? Do I miss something?
epsilon is too small. BOOST_CHECK_CLOSE treats the argument as a percent, so there's an extra factor of 0.01, which means that this comparison is effectively for equality. In Christ, Steven Watanabe
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Wednesday, March 31, 2010 3:35 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [Boost.UTF] Strange (failed) result on comparing floats
AMDG
Olaf Peter wrote:
I'm checking some data of consistence using boost's unit test framework (1.42):
BOOST_CHECK_CLOSE( *v[1].y.max, -43.0e-3, std::numeric_limits<double>::epsilon() );
which fails with:
difference{1.6137e-14%} between *v[1].y.max{-0.043000000000000003} and -43.0e-3{-0.042999999999999997} exceeds 2.2204460492503131e-16%
where v is a std::vector,y a struct and max a boost::optional<double>. The data where parsed by boost.spirit. This is the only failed test case from 16 parsed doubles. What's gone wrong here? Do I miss something?
epsilon is too small. BOOST_CHECK_CLOSE treats the argument as a percent, so there's an extra factor of 0.01, which means that this comparison is effectively for equality.
Well spotted Steven. BOOST_CHECK_CLOSE_FRACTION( *v[1].y.max, -43.0e-3, std::numeric_limits<double>::epsilon() ); is what you meant? Our esteemed and illustrious author of the invaluable Test library was begged not to use percents but ... Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
Paul A. Bristow schrieb:
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Wednesday, March 31, 2010 3:35 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] [Boost.UTF] Strange (failed) result on comparing floats
AMDG
Olaf Peter wrote:
I'm checking some data of consistence using boost's unit test framework (1.42):
BOOST_CHECK_CLOSE( *v[1].y.max, -43.0e-3, std::numeric_limits<double>::epsilon() );
which fails with:
difference{1.6137e-14%} between *v[1].y.max{-0.043000000000000003} and -43.0e-3{-0.042999999999999997} exceeds 2.2204460492503131e-16%
where v is a std::vector,y a struct and max a boost::optional<double>. The data where parsed by boost.spirit. This is the only failed test case from 16 parsed doubles. What's gone wrong here? Do I miss something?
epsilon is too small. BOOST_CHECK_CLOSE treats the argument as a percent, so there's an extra factor of 0.01, which means that this comparison is effectively for equality.
Well spotted Steven.
BOOST_CHECK_CLOSE_FRACTION( *v[1].y.max, -43.0e-3, std::numeric_limits<double>::epsilon() );
is what you meant?
Yes, Thanks!
Our esteemed and illustrious author of the invaluable Test library was begged not to use percents but ...
why this? Olaf
Olaf Peter
Our esteemed and illustrious author of the invaluable Test library was begged not to use percents but ...
why this?
1. Backward compatibility 2. In laymen terms it's easier to understand % based comparison: a different from b by x percent. Otherwise you need to understand notion of relative error, which may not be the case unless you expert in the field. One other point is that the error message clearly referred to the %. It should have gave you a hint. Gennadiy
participants (4)
-
Gennadiy Rozental -
Olaf Peter -
Paul A. Bristow -
Steven Watanabe