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?