[OpenBSD] Incorrect std::numeric_limits?
Hello, From the test results at: http://tinyurl.com/ezs3o It appears that std::numeric_limits<long double> might be defined incorrectly on OpenBSD on x86 (for example, the 1 + epsilon != 1 test is failing for long double). Is there someone with access to this operating system who can look into this? On FreeBSD long doubles are defined as having the same accuracy as doubles, so maybe that's the case for OpenBSD as well? Another possibility is that OpenBSD doesn't have floating point functions defined for long doubles - but that wouldn't explain why the epsilon test is failing. thanks, Daniel
Daniel James wrote:
Hello,
From the test results at:
It appears that std::numeric_limits<long double> might be defined incorrectly on OpenBSD on x86 (for example, the 1 + epsilon != 1 test is failing for long double). Is there someone with access to this operating system who can look into this?
On FreeBSD long doubles are defined as having the same accuracy as doubles, so maybe that's the case for OpenBSD as well? Another possibility is that OpenBSD doesn't have floating point functions defined for long doubles - but that wouldn't explain why the epsilon test is failing.
There are a couple of problems: and you are correct on both counts, there are no long double versions of the math functions (there are no *l versions, the std::func versions do have long double overloads but they call the double versions internally). And numeric_limits<long double> is wrong as well, see http://tinyurl.com/mof7j In fact numeric_limits<long double> has some really strange properties: it's min/max values correspond to an 80-bit long double with an extended exponent range, but the digits and epsilon values are those of a 64-bit double. Oh but LDBL_EPSILON and LDBL_MANT_DIG are correct! So go figure :-( BTW the math_info program results were designed to diagnose precisely these kinds of issues, HTH, John.
On 25/09/06, John Maddock <john@johnmaddock.co.uk> wrote:
There are a couple of problems: and you are correct on both counts, there are no long double versions of the math functions (there are no *l versions, the std::func versions do have long double overloads but they call the double versions internally). And numeric_limits<long double> is wrong as well, see http://tinyurl.com/mof7j
In fact numeric_limits<long double> has some really strange properties: it's min/max values correspond to an 80-bit long double with an extended exponent range, but the digits and epsilon values are those of a 64-bit double. Oh but LDBL_EPSILON and LDBL_MANT_DIG are correct!
That's on FreeBSD, my problem was with OpenBSD (http://tinyurl.com/o6rty) but it seems that both are wrong. OpenBSD is the other way round, the macros say that long double is 64-bit but numeric_limits claims 80-bit. So it ends up with numeric_limits::min()==0, max()==inf. Hopefully all I have to do is use the macros for the BSDs.
BTW the math_info program results were designed to diagnose precisely these kinds of issues,
HTH,
Very helpful, thank you. I'll look at it closer tonight. Daniel
On 25/09/06, John Maddock <john@johnmaddock.co.uk> wrote: That's on FreeBSD, my problem was with OpenBSD (http://tinyurl.com/o6rty) but it seems that both are wrong. OpenBSD is the other way round, the macros say that long double is 64-bit but numeric_limits claims 80-bit. So it ends up with numeric_limits::min()==0, max()==inf. Hopefully all I have to do is use the macros for the BSDs.
But this doesn't solve the problem. I'll look at this problem when I get an access to my notebook with *BSD installed. So far I see only that min returns __LDBL_MIN__ (http://tinyurl.com/lxl85) but I can't find a definition of __LDBL_MIN__ using web access to OpenBSD's cvs. -- Alexander Nasonov
participants (3)
-
Alexander Nasonov -
Daniel James -
John Maddock