Re: [Boost-users] [Math] Accuracy test failures on QNX 6.4.0

Subject: Re: [Boost-users] [Math] Accuracy test failures on QNX 6.4.0
From: John Maddock (john_at_[hidden])
Date: 2008-11-20 05:51:59

Niklas Angare wrote:
>>> Thanks, but I admit to being stuck... somewhere around line 320 of
>>> boost/math/tools/roots.hpp there's a NaN being generated for type
>>> real_concept, but not for type long double (and real_concept is
>>> just a very thin wrapper around long double).  Can you set a
>>> breakpoint at that location and see what the problem is?
>>
>> It's on line 299, f(result), which in the end results in a call to
>> std::pow(0.5, 16.182502746582031), the result of which is a NaN...
>> The numbers may not be exact since they're just from the debugger's
>> presentation. I've attached the call stack.
>>
>> After some experimentation I arrived at this test:
>> #include <cmath>
>> #include <iostream>
>> #include <iomanip>
>> #include <limits>
>>
>> int main()
>> {
>> typedef std::numeric_limits<long double> ldlimits;
>> unsigned int raw1[3]; // garbage
>> unsigned int raw2[3]; // garbage
>> long double a = 0.5L;
>> long double b1 = 16.182502746582031;
>> long double b2 = 16.182502746582031L;
>> long double b3 = 1.0L; // garbage
>> long double b4 = 2.0L; // garbage
>> long double r1 = std::pow(a, b1);
>> long double r2 = std::pow(a, b2);
>> long double r3 = std::pow(a, b3); // garbage
>> #ifdef VERSION2
>> long double r4 = std::pow(a, b4); // garbage
>> #endif
>> std::cout << std::setprecision(30);
>> std::cout << ldlimits::radix << "^" << ldlimits::digits
>>          << " (" << sizeof(long double) << ")" << std::endl;
>> std::cout << "1) " << b1 << " " << r1 << std::endl;
>> std::cout << "2) " << b2 << " " << r2 << std::endl;
>> }
>>
>>
>> Results with VERSION2 undefined:
>> 2^64 (12)
>> 1) 16.18250274658203125 nan
>> 2) 16.18250274658203099988 1.3445633476723758172e-05
>>
>>
>> Results with VERSION2 defined:
>> 2^64 (12)
>> 1) 16.18250274658203125 1.3445633476723755844e-05
>> 2) 16.18250274658203099988 1.3445633476723758172e-05
>>
>>
>> I discovered 1) when I forgot to put the L on the literal. Then I
>> discovered that the result is sometimes correct depending on other
>> nearby code. Seriously weird. Any ideas what could be causing this?

Ummm, so you get a NaN or not depending upon what other code is present but 
not even called yet????

That's too weird, and looks like a platform bug if I've understood you 
correctly... but on the off chance there's some issue with FPU exception 
flags from previous calls messing things up, can you try the attached 
boost/math/tools/config.hpp and see if it clears any of the test failures?

Thanks, John.