Niklas Angare wrote:
Any feedback from QNX on the cause of the issue? It would be nice understand what's going on just in case it's something we can fix.
Nothing yet. I've reported the issue here: http://community.qnx.com/sf/go/projects.core_os/discussion.newcode.topc5091
Ah no, there really was a bug in the Boost.Math code that was exposed by a less than fully accurate fmod implementation on that platform.
Is this and the other accuracy problems something to worry about when doing simple calculations with doubles?
Maybe, maybe not :-( The default behaviour is that to ensure accuracy, each special function is actually evaluated internally at the next available precision up - so for example: tgamma<float> evaluated at double precision internally. tgamma<double> evaluated at long double precision internally. There are configuration macros to change this behaviour if needed (or just disable long double support full stop): but for now the double-precision tests all appear to be passing. It's a worry though :-( John.