Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Boris Gubenko wrote:
I'm checking with the OS folks and will report back here, for both HP-UX/ia64 and Tru64 Alpha.
And the answer is:
You are correct that both platforms are capable of executing in either endianness. However, the operating systems operate in only one. HP-UX is *always* big endian Tru64 is *always* little endian [...] Summary: A compile time check is adequate.
So, with current <endian.hpp>, I think, that we are all set for these platforms. Thanks, Boris ----- Original Message ----- From: "Boris Gubenko" <Boris.Gubenko@hp.com> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Tuesday, October 17, 2006 9:12 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Now endian.hpp defines BOOST_BIG_ENDIAN on HP-UX. This was suggested by Boris Gubenko.
If you are right John, then this seems to be incorrect. Shouldn't endian.hpp then define something like BOOST_UNKNOWN_ENDIAN on HP-UX?
Boris, do you have any comments on this?
I'm checking with the OS folks and will report back here, for both HP-UX/ia64 and Tru64 Alpha.
Thanks, Boris
----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Tuesday, October 17, 2006 9:00 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
John Maddock wrote:
I'm not completely certain, but I believe HP-UX falls into this category: the idea is that you can pass binary data from one platform to another, and just switch the endianness bit to access it natively (think distributed applications).
Now endian.hpp defines BOOST_BIG_ENDIAN on HP-UX. This was suggested by Boris Gubenko.
If you are right John, then this seems to be incorrect. Shouldn't endian.hpp then define something like BOOST_UNKNOWN_ENDIAN on HP-UX?
Boris, do you have any comments on this?
Then my fpclassify could use a fast implementation when BOOST_BIG_ENDIAN or BOOST_LITTLE_ENDIAN is defined and a slower implementation when BOOST_UNKNOWN_ENDIAN is defined.
--Johan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
Boris Gubenko wrote:
I'm checking with the OS folks and will report back here, for both HP-UX/ia64 and Tru64 Alpha.
And the answer is:
You are correct that both platforms are capable of executing in either endianness. However, the operating systems operate in only one. HP-UX is *always* big endian Tru64 is *always* little endian [...] Summary: A compile time check is adequate.
So, with current <endian.hpp>, I think, that we are all set for these platforms.
Thanks, Boris
Excellent. Thanks for the help. --Johan
I've got some additional comments about the endian'ness of HP-UX -- see attached. To our slight embarrassment, while HP-UX/ia64 does predefine _BIG_ENDIAN macro, our other big-endian platform -- PA-RISC -- does not. However, the proposed fallback strategy is guaranteed to generate the correct result for a platform where neither _BIG_ENDIAN nor _LITTLE_ENDIAN macro is defined. If people think, that this is a good idea to check _BIG_ENDIAN/ _LITTLE_ENDIAN macro first and, then, fall back to OS/architecture check, I can submit an obvious, trivial patch for endian.hpp. To me, the crux of the matter is that while little-endian HP-UX/ia64 is a remote possibility, it is not completely impossible. And if this creature ever comes to existence, it will define _LITTLE_ENDIAN macro, so the endian'ness check will continue to work. "
A compile time check is adequate.
True, but the proper way to check at compile time is to test for one of the _BIG_ENDIAN or _LITTLE_ENDIAN macros. I believe most or all of the big-endian Unix platforms define _BIG_ENDIAN = 1, but few of the little-endian platforms define _LITTLE_ENDIAN. So I'd suggest checking for one of the two macros, and then, only if neither of them is set, fall back to checking the OS and architecture. By the way, while unlikely, a little-endian HP-UX ABI on Integrity isn't completely out of the question at some point in the future. We already have the ability to compile little-endian code with our HP-UX compiler, and the _BIG_ENDIAN macro is the way to tell which option was used. " And more of the discussion: "
The real question is: is little-endian HP-UX ABI on Integrity more than just an academic exercise? How can such code operate on a big-endian OS?
Maybe not today, but who knows tomorrow? As I said, it may be unlikely, but not so much so to completely ignore the possibility. Checking for the appropriate macros first means the code won't have to be changed if and when that possibility ever becomes reality. The endianness is selected in the user mask portion of the PSR, so it's completely under the application's control. We run Linux executables today on HP-UX simply by having a layer that does the endian switch at the system call boundary. " ----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Tuesday, October 17, 2006 11:43 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Boris Gubenko wrote:
Boris Gubenko wrote:
I'm checking with the OS folks and will report back here, for both HP-UX/ia64 and Tru64 Alpha.
And the answer is:
You are correct that both platforms are capable of executing in either endianness. However, the operating systems operate in only one. HP-UX is *always* big endian Tru64 is *always* little endian [...] Summary: A compile time check is adequate.
So, with current <endian.hpp>, I think, that we are all set for these platforms.
Thanks, Boris
Excellent. Thanks for the help.
--Johan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
I've got some additional comments about the endian'ness of HP-UX -- see attached. To our slight embarrassment, while HP-UX/ia64 does predefine _BIG_ENDIAN macro, our other big-endian platform -- PA-RISC -- does not. However, the proposed fallback strategy is guaranteed to generate the correct result for a platform where neither _BIG_ENDIAN nor _LITTLE_ENDIAN macro is defined.
If people think, that this is a good idea to check _BIG_ENDIAN/ _LITTLE_ENDIAN macro first and, then, fall back to OS/architecture check, I can submit an obvious, trivial patch for endian.hpp.
To me, the crux of the matter is that while little-endian HP-UX/ia64 is a remote possibility, it is not completely impossible. And if this creature ever comes to existence, it will define _LITTLE_ENDIAN macro, so the endian'ness check will continue to work.
"
A compile time check is adequate.
True, but the proper way to check at compile time is to test for one of the _BIG_ENDIAN or _LITTLE_ENDIAN macros. I believe most or all of the big-endian Unix platforms define _BIG_ENDIAN = 1, but few of the little-endian platforms define _LITTLE_ENDIAN. So I'd suggest checking for one of the two macros, and then, only if neither of them is set, fall back to checking the OS and architecture.
By the way, while unlikely, a little-endian HP-UX ABI on Integrity isn't completely out of the question at some point in the future. We already have the ability to compile little-endian code with our HP-UX compiler, and the _BIG_ENDIAN macro is the way to tell which option was used. "
I think the file <endian.hpp> needs to be refactored. It is turning into a mess. We need to make it clearer that it is a decision tree: 1. Is it GCC? Use header <endian.h> 2. If not, does the processor have a unique endianness? 3. If not, does the OS / processor combo have a unique endianness? 4. If not, are any macros such as _LITTLE_ENDIAN defined. But in the meantime, why not add the patch. --Johan
Johan Råde wrote:
I think the file <endian.hpp> needs to be refactored. It is turning into a mess. We need to make it clearer that it is a decision tree:
1. Is it GCC? Use header <endian.h>
2. If not, does the processor have a unique endianness?
3. If not, does the OS / processor combo have a unique endianness?
4. If not, are any macros such as _LITTLE_ENDIAN defined.
But in the meantime, why not add the patch.
And speaking of that, does anyone know: Is the combo Windows / ia64 always LE? is the combo Linux / Intel C++ / ia64 always LE? --Johan
Johan Rede wrote:
But in the meantime, why not add the patch.
Will submit a patch later today. Boris ----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Thursday, October 19, 2006 8:35 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Boris Gubenko wrote:
I've got some additional comments about the endian'ness of HP-UX -- see attached. To our slight embarrassment, while HP-UX/ia64 does predefine _BIG_ENDIAN macro, our other big-endian platform -- PA-RISC -- does not. However, the proposed fallback strategy is guaranteed to generate the correct result for a platform where neither _BIG_ENDIAN nor _LITTLE_ENDIAN macro is defined.
If people think, that this is a good idea to check _BIG_ENDIAN/ _LITTLE_ENDIAN macro first and, then, fall back to OS/architecture check, I can submit an obvious, trivial patch for endian.hpp.
To me, the crux of the matter is that while little-endian HP-UX/ia64 is a remote possibility, it is not completely impossible. And if this creature ever comes to existence, it will define _LITTLE_ENDIAN macro, so the endian'ness check will continue to work.
"
A compile time check is adequate.
True, but the proper way to check at compile time is to test for one of the _BIG_ENDIAN or _LITTLE_ENDIAN macros. I believe most or all of the big-endian Unix platforms define _BIG_ENDIAN = 1, but few of the little-endian platforms define _LITTLE_ENDIAN. So I'd suggest checking for one of the two macros, and then, only if neither of them is set, fall back to checking the OS and architecture.
By the way, while unlikely, a little-endian HP-UX ABI on Integrity isn't completely out of the question at some point in the future. We already have the ability to compile little-endian code with our HP-UX compiler, and the _BIG_ENDIAN macro is the way to tell which option was used. "
I think the file <endian.hpp> needs to be refactored. It is turning into a mess. We need to make it clearer that it is a decision tree:
1. Is it GCC? Use header <endian.h>
2. If not, does the processor have a unique endianness?
3. If not, does the OS / processor combo have a unique endianness?
4. If not, are any macros such as _LITTLE_ENDIAN defined.
But in the meantime, why not add the patch.
--Johan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
Will submit a patch later today.
Attached the patch. Tested on: HP-UX/ia64 and PA-RISC with aCC and gcc Tru64 Alpha with cxx and gcc Linux/ia64 with icc and gcc Index: endian.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/detail/endian.hpp,v retrieving revision 1.4 diff -r1.4 endian.hpp 39a40,45
#elif defined(_BIG_ENDIAN) # define BOOST_BIG_ENDIAN # define BOOST_BYTE_ORDER 4321 #elif defined(_LITTLE_ENDIAN) # define BOOST_LITTLE_ENDIAN # define BOOST_BYTE_ORDER 1234
----- Original Message ----- From: "Boris Gubenko" <Boris.Gubenko@hp.com> To: <boost@lists.boost.org> Cc: "Boris Gubenko" <Boris.Gubenko@hp.com> Sent: Thursday, October 19, 2006 8:56 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc Johan Rede wrote:
But in the meantime, why not add the patch.
Will submit a patch later today. Boris ----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Thursday, October 19, 2006 8:35 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Boris Gubenko wrote:
I've got some additional comments about the endian'ness of HP-UX -- see attached. To our slight embarrassment, while HP-UX/ia64 does predefine _BIG_ENDIAN macro, our other big-endian platform -- PA-RISC -- does not. However, the proposed fallback strategy is guaranteed to generate the correct result for a platform where neither _BIG_ENDIAN nor _LITTLE_ENDIAN macro is defined.
If people think, that this is a good idea to check _BIG_ENDIAN/ _LITTLE_ENDIAN macro first and, then, fall back to OS/architecture check, I can submit an obvious, trivial patch for endian.hpp.
To me, the crux of the matter is that while little-endian HP-UX/ia64 is a remote possibility, it is not completely impossible. And if this creature ever comes to existence, it will define _LITTLE_ENDIAN macro, so the endian'ness check will continue to work.
"
A compile time check is adequate.
True, but the proper way to check at compile time is to test for one of the _BIG_ENDIAN or _LITTLE_ENDIAN macros. I believe most or all of the big-endian Unix platforms define _BIG_ENDIAN = 1, but few of the little-endian platforms define _LITTLE_ENDIAN. So I'd suggest checking for one of the two macros, and then, only if neither of them is set, fall back to checking the OS and architecture.
By the way, while unlikely, a little-endian HP-UX ABI on Integrity isn't completely out of the question at some point in the future. We already have the ability to compile little-endian code with our HP-UX compiler, and the _BIG_ENDIAN macro is the way to tell which option was used. "
I think the file <endian.hpp> needs to be refactored. It is turning into a mess. We need to make it clearer that it is a decision tree:
1. Is it GCC? Use header <endian.h>
2. If not, does the processor have a unique endianness?
3. If not, does the OS / processor combo have a unique endianness?
4. If not, are any macros such as _LITTLE_ENDIAN defined.
But in the meantime, why not add the patch.
--Johan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
John, Could you test the latest version (ver. 13) of my fpclassify library? It is available in the vault in the directory Math-Numerics. The library is based on a helper class fp_traits<T> that contains information about the binary representation of T. Here T = float, double or long double. The generic version of fp_traits<T> is initialized at run time, and is hence safe but also slow. Then there are fast specializations of fp_traits<T> for different floating point types T, operating systems and processors. The library does not use the limits and boost/endian.hpp headers. The library has been tested on the following platforms: Win / MSVC 7.1 / x86 Mac / GCC 3.3, GCC 4.0 / ppc Linux / GCC 3.3 / x86, x64, ia64, ppc, hppa, mips, m68k Let's see if you can break it! --Johan
Johan Råde wrote:
John,
Could you test the latest version (ver. 13) of my fpclassify library? It is available in the vault in the directory Math-Numerics.
The library is based on a helper class fp_traits<T> that contains information about the binary representation of T. Here T = float, double or long double. The generic version of fp_traits<T> is initialized at run time, and is hence safe but also slow. Then there are fast specializations of fp_traits<T> for different floating point types T, operating systems and processors.
The library does not use the limits and boost/endian.hpp headers.
The library has been tested on the following platforms:
Win / MSVC 7.1 / x86 Mac / GCC 3.3, GCC 4.0 / ppc Linux / GCC 3.3 / x86, x64, ia64, ppc, hppa, mips, m68k
Let's see if you can break it!
OK :-) HP testdrive is down at present, so I can only test on Win32: Intel 8 and 9 pass, but Intel 7 fails: $ icl -GX -I.. -I../../release/boost -Ox *.cpp Intel(R) C++ Compiler for 32-bit applications, Version 7.1 Build 20040309Z Copyright (C) 1985-2004 Intel Corporation. All rights reserved. test.cpp Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved. -out:test.exe test.obj John Maddock@fuji /cygdrive/c/data/boost/fpclassify/test $ ./test.exe Testing float Assertion failed: !(isinf)(x), file test.cpp, line 242 abnormal program termination I'll try again on the testdrive machines later. John.
John Maddock wrote:
Intel 8 and 9 pass, but Intel 7 fails:
$ icl -GX -I.. -I../../release/boost -Ox *.cpp Intel(R) C++ Compiler for 32-bit applications, Version 7.1 Build 20040309Z Copyright (C) 1985-2004 Intel Corporation. All rights reserved. test.cpp Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
-out:test.exe test.obj
John Maddock@fuji /cygdrive/c/data/boost/fpclassify/test $ ./test.exe Testing float Assertion failed: !(isinf)(x), file test.cpp, line 242
abnormal program termination
That is weird. Can you run the inspect tool (fpclassify/tools/inspect/inspect.cpp) on Win32 / Intel 7? --Johan
Johan Råde wrote:
That is weird. Can you run the inspect tool (fpclassify/tools/inspect/inspect.cpp) on Win32 / Intel 7?
I don't think it differs from any other Win32 compiler: This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn. min 00 00 00 01 n. min 00 80 00 00 1 3f 80 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf 7f 80 00 00 q. nan ff c0 00 00 s. nan ff 80 00 00 -1 bf 80 00 00 ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn. min 00 00 00 00 00 00 00 01 n. min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf 7f f0 00 00 00 00 00 00 q. nan ff f8 00 00 00 00 00 00 s. nan ff f0 00 00 00 00 00 00 -1 bf f0 00 00 00 00 00 00 ---------- long double -------------- 0 00 00 00 00 00 00 00 00 sn. min 00 00 00 00 00 00 00 01 n. min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf 7f f0 00 00 00 00 00 00 q. nan ff f8 00 00 00 00 00 00 s. nan ff f0 00 00 00 00 00 00 -1 bf f0 00 00 00 00 00 00 John.
John Maddock wrote:
Johan Råde wrote:
That is weird. Can you run the inspect tool (fpclassify/tools/inspect/inspect.cpp) on Win32 / Intel 7?
I don't think it differs from any other Win32 compiler:
s. nan ff 80 00 00
It certainly does differ. All bits in the mantissa are zero. It is the IEEE754 binary representation of negative infinity. Here is what I get on my Win32 / MSVS 7.1 / ia32 platform s. nan 7f 80 00 01 There is the same problem for double and long double. Looks like Intel 7 on Win32 has a broken numeric_limits<T>::signalling_NaN(). --Johan
Johan Råde wrote:
Let's see if you can break it!
OK, I can break it on HP aCC with: maddock@td176> aCC -AA -Ofaster -I../ -I ~ *.cpp maddock@td176> ./a.out Testing float Assertion failed: (fpclassify)(x) == FP_SUBNORMAL, file test.cpp, line 122 ABORT instruction (core dumped) However the docs for -Ofaster do indicate that denorms don't work correctly, so it may be that problem here :-) g++ on HP-UX looks OK. On Linux/IA64, with Intel C++ 9.1 maddock@td178.testdrive.hp.com> icc -O3 -I.. -I ~ *.cpp -static maddock@td178.testdrive.hp.com> ./a.out Testing float a.out: test.cpp:139: void <unnamed>::test_basic() [with T = float]: Assertion `(fpclassify)(x) == FP_SUBNORMAL' failed. Aborted Intel on IA32 looks OK, though I didn't try very hard to break things :-) And I couldn't find an AMD64 machine with Intel for EM64 installed to test on. Regards, John.
John, Thanks a lot for running these tests. Here is a summary of what you have done (could you double check that I've got the operating systems / compilers / processors right), and my interpretation of the results: ---- pass ---- Win32 / Intel 8.? / ia32 Win32 / Intel 9.1 / ia32 Linux / Intel 9.1 / ia32 HP-UX / GCC ? / ia64 ---- fail ---- Win32 / Intel 7.? / ia32 where: basic_test<float> line 242 what: !isinf(signalling_NaN()) why: broken numeric_limits<T>::signalling_NaN HP-UX / aCC / ia64 where: basic_test<float> line 122 what: fpclassify(denorm_min()) == FP_SUBNORMAL why: multiple definitions of FP_SUBNORMAL ? Linux / Intel 9.1 / ia64 where: basic_test<float> line 139 what: !isnormal(min()/2) why: broken numeric_limits<T>::min ? Could you run the inspect tool on the last two platforms as well? --Johan
Johan Råde wrote:
John,
Thanks a lot for running these tests.
Here is a summary of what you have done (could you double check that I've got the operating systems / compilers / processors right), and my interpretation of the results:
---- pass ----
Win32 / Intel 8.? / ia32 Win32 / Intel 9.1 / ia32 Linux / Intel 9.1 / ia32 HP-UX / GCC ? / ia64
Add to that HP aCC with -O4.
---- fail ----
Win32 / Intel 7.? / ia32
where: basic_test<float> line 242 what: !isinf(signalling_NaN()) why: broken numeric_limits<T>::signalling_NaN
Not sure about that: the std lib is the same as that used by VC6, however these are both old compilers now, so maybe ignor this one for now (your code doesn't compile on VC6 anyway).
HP-UX / aCC / ia64
where: basic_test<float> line 122 what: fpclassify(denorm_min()) == FP_SUBNORMAL why: multiple definitions of FP_SUBNORMAL ?
I don't think that's the cause: it passes with -O4 but not -Ofaster. The docs for -Ofaster state that it breaks code that relies on denorms, and it's noticable that your first denorm test passes, but the second (which negates denorm_min()) fails. I suspect that the negation of the denorm causes it to round down to zero maybe?
Linux / Intel 9.1 / ia64
where: basic_test<float> line 139 what: !isnormal(min()/2) why: broken numeric_limits<T>::min ?
I don't believe that's the cause: the test passes when built in debug mode, or with -O1, but fails with -O2 or -O3, so it's an optimiser issue again. My suspicion would be that: x = (std::numeric_limits<T>::min)() / 2; either underflows to zero, or is evaluated by the compiler at compile time maybe?
Could you run the inspect tool on the last two platforms as well?
Here's HP-UX: maddock@td176> aCC -AA -I../../ -I ~ -Ofaster *.cpp maddock@td176> ./a.out This platform is big-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 000 00 00 00 sn. min00 00 00 01 n. min00 80 00 00 13f 80 00 00 4/33f aa aa ab max7f 7f ff ff inf7f 80 00 00 q. nan7f c0 00 00 s. nan7f a0 00 00 -1bf 80 00 00 ---------- double ------------------- 000 00 00 00 00 00 00 00 sn. min00 00 00 00 00 00 00 01 n. min00 10 00 00 00 00 00 00 13f f0 00 00 00 00 00 00 4/33f f5 55 55 55 55 55 55 max7f ef ff ff ff ff ff ff inf7f f0 00 00 00 00 00 00 q. nan7f f8 00 00 00 00 00 00 s. nan7f f4 00 00 00 00 00 00 -1bf f0 00 00 00 00 00 00 ---------- long double -------------- 000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn. min00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 n. min00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 13f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4/33f ff 55 55 55 55 55 55 55 55 55 55 55 55 55 55 max7f fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff inf7f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 q. nan7f ff 80 00 00 00 00 00 00 00 00 00 00 00 00 00 s. nan7f ff 40 00 00 00 00 00 00 00 00 00 00 00 00 00 -1bf ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 And Intel on Linux/IA64 maddock@td178.testdrive.hp.com> icc -O3 -I../../ -I ~ *.cpp -static maddock@td178.testdrive.hp.com> ./a.out This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn. min 00 00 00 01 n. min 00 80 00 00 1 3f 80 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf 7f 80 00 00 q. nan 7f e0 00 00 s. nan 7f a0 00 00 -1 bf 80 00 00 ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn. min 00 00 00 00 00 00 00 01 n. min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf 7f f0 00 00 00 00 00 00 q. nan 7f fc 00 00 00 00 00 00 s. nan 7f f4 00 00 00 00 00 00 -1 bf f0 00 00 00 00 00 00 ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn. min 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 n. min 00 00 00 00 00 00 00 00 80 00 00 00 00 00 00 00 1 00 00 00 00 00 00 3f ff 80 00 00 00 00 00 00 00 4/3 00 00 00 00 00 00 3f ff aa aa aa aa aa aa aa ab max 00 00 00 00 00 00 7f fe ff ff ff ff ff ff ff ff inf 00 00 00 00 00 00 7f ff 80 00 00 00 00 00 00 00 q. nan 00 00 00 00 00 00 7f ff e0 00 00 00 00 00 00 00 s. nan 00 00 00 00 00 00 7f ff a0 00 00 00 00 00 00 00 -1 00 00 00 00 00 00 bf ff 80 00 00 00 00 00 00 00 Can I make a couple of suggestions with respect to your test program? 1) It would be useful if the asserts were changed to something that didn't abort so we could see all the possible failures at once. 2) It would be useful if failed tests printed out the binary representation of the failed value (merge the inspect tool into the test. 3) It would help to check whether numeric_limits::has_infinity/has_denorm etc is true before testing those features. 4) It might pay to sanity check that denorm test values aren't zero or >= numeric_limits<>::min() before using them. That would catch out clever compilers right away: there's no point in testing for a denorm if the value isn't a denorm! :-) HTH, John.
John Maddock wrote:
Johan Råde wrote:
Win32 / Intel 7.? / ia32
where: basic_test<float> line 242 what: !isinf(signalling_NaN()) why: broken numeric_limits<T>::signaling_NaN
Not sure about that: the std lib is the same as that used by VC6, however these are both old compilers now, so maybe ignor this one for now (your code doesn't compile on VC6 anyway).
I'm quite sure. Which of the following two facts are you not sure about? ;-) Fact 1: numeric_limits<float>::signaling_NaN on Win32/Intel 7/ia32 returns a number with binary expansion ff 80 00 00 Fact 2: Under the IEEE754 standard, ff 80 00 00 is the binary expansion of single precision negative infinity. I will disable the signaling_NaN tests on Intel <= 7.
HP-UX / aCC / ia64
where: basic_test<float> line 122 what: fpclassify(-denorm_min()) == FP_SUBNORMAL why: multiple definitions of FP_SUBNORMAL ?
I suspect that the negation of the denorm causes it to round down to zero maybe?
I agree. Your suggestion 4 below should take care of that.
Linux / Intel 9.1 / ia64
where: basic_test<float> line 139 what: fpclassify(min()/2) == FP_SUBNORMAL why: broken numeric_limits<T>::min ?
My suspicion would be that:
x = (std::numeric_limits<T>::min)() / 2;
either underflows to zero, or is evaluated by the compiler at compile time maybe?
I agree. Your suggestion 4 below should take care of that.
Could you run the inspect tool on the last two platforms as well?
Here's HP-UX:
[snip]
And Intel on Linux/IA64
[snip] The results are as expected.
Can I make a couple of suggestions with respect to your test program?
1) It would be useful if the asserts were changed to something that didn't abort so we could see all the possible failures at once. 2) It would be useful if failed tests printed out the binary representation of the failed value (merge the inspect tool into the test. 3) It would help to check whether numeric_limits::has_infinity/has_denorm etc is true before testing those features. 4) It might pay to sanity check that denorm test values aren't zero or >= numeric_limits<>::min() before using them. That would catch out clever compilers right away: there's no point in testing for a denorm if the value isn't a denorm! :-)
I agree with all 4 suggestions. And time spent building good tools usually pays off. I will do 3 and 4, and add -denorm_min and min/2 to the inspect tool today. I will do 1 and 2 later. --Johan
Johan Råde wrote:
I agree with all 4 suggestions. And time spent building good tools usually pays off.
I will do 3 and 4, and add -denorm_min and min/2 to the inspect tool today.
Done, and uploaded to the vault.
I will do 1 and 2 later.
--Johan
Version 15 has been uploaded to the vault. It works with VC 6.5. The tests handle broken signaling_NaN on Intel 7 and VC 6. (std::numeric_limits<T>::signaling_NaN() returns negative infinity!) The tests handle platforms where denorms may be rounded of to zero. --Johan
Johan Råde wrote:
Version 15 has been uploaded to the vault.
John, There are some problems with version 15. Don't bother to run any tests. I did some tests with VC6.5: qnan == qnan is false snan == snan is true qnan == inf is false qnan == -inf is false snan == inf is false snan == -inf is true std::numeric_limits<T>::signaling_NaN() does return negative infinity. --Johan
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Johan Råde | Sent: 13 November 2006 14:37 | To: boost@lists.boost.org | Subject: Re: [boost] Optimized portable isnan, isfinite, | fpclassify etc | | Johan Råde wrote: | > Version 15 has been uploaded to the vault. | | John, | | There are some problems with version 15. | Don't bother to run any tests. | | I did some tests with VC6.5: | | qnan == qnan is false | snan == snan is true | qnan == inf is false | qnan == -inf is false | snan == inf is false | snan == -inf is true | | std::numeric_limits<T>::signaling_NaN() does return negative infinity. This was a feature - I complained about it to PJP many years ago - after thinking I was terminally confused. I believe is has been corrected. I suggest you/we stop trying to support this obselete version of the library. It will only encourage people to keep on (ab-)using it ;-) Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Paul A Bristow wrote:
| Johan Råde wrote:
| I did some tests with VC6.5: [snip] | std::numeric_limits<T>::signaling_NaN() does return negative infinity.
This was a feature - I complained about it to PJP many years ago - after thinking I was terminally confused. I believe is has been corrected.
I suggest you/we stop trying to support this obselete version of the library. It will only encourage people to keep on (ab-)using it ;-)
Paul
VC 6.5 is on the list of platforms officially supported by Boost. Maybe it should be removed. It is hard for me to imagine that anyone still uses it. ------------------- I have uploaded a new version of fpclassify, ver 16, that has been tested on Win / VC 6.5, 7.1 / x86 Mac / GCC 3.3, GCC 4.0 / PowerPC Next a friend of mine will test on Linux / GCC 3.3 and half a dozen different processors. John, once that is done, you could try again. --Johan
----Original Message---- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Johan Råde Sent: 13 November 2006 16:41 To: boost@lists.boost.org Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Paul A Bristow wrote:
Johan Råde wrote:
I did some tests with VC6.5: [snip] std::numeric_limits<T>::signaling_NaN() does return negative infinity.
This was a feature - I complained about it to PJP many years ago - after thinking I was terminally confused. I believe is has been corrected.
I suggest you/we stop trying to support this obselete version of the library. It will only encourage people to keep on (ab-)using it ;-)
Paul
VC 6.5 is on the list of platforms officially supported by Boost.
I don't think there really is such a thing as "THE list of platforms supported by Boost". Different libraries support different platforms. Some libraries continue to support VC 6.5, but there is no reason for a new library to make an effort to support it.
It is hard for me to imagine that anyone still uses it.
We are still using VC5 for some code. (We skipped VC6.x and then went straight to VC7). -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB24 6WZ, ENGLAND Tel: +44 (0)1223 203894
Martin Bonner wrote: [snip]
VC 6.5 is on the list of platforms officially supported by Boost.
I don't think there really is such a thing as "THE list of platforms supported by Boost". Different libraries support different platforms. Some libraries continue to support VC 6.5, but there is no reason for a new library to make an effort to support it.
There is a list at the bottom of the web page www.boost.org. That is the list I referred to. [snip]
We are still using VC5 for some code. (We skipped VC6.x and then went straight to VC7).
Are you running boost on VC5? --Johan
From: Johan Råde Sent: 14
Martin Bonner wrote:
We are still using VC5 for some code. (We skipped VC6.x and then went straight to VC7).
Are you running boost on VC5? No, but if I had learnt about boost three years ago, we might well be using some of the more established and stable boost libraries. shared_ptr and array spring to mind.
These days there is very little development of the VC5 code. We are not likely to add boost to it know. My points are: - I am sure there are a number of significant projects still actively using VC6.5 - Such projects are unlikely to want to switch to a new version of boost. - There is no particular reason new libraries should worry about supporting VC6.5 and good reason not to worry about it (it takes precious developer resource). If it happens to work that's great, it not, tough. -- Martin Bonner Martin.Bonner@Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB24 6WZ, ENGLAND Tel: +44 (0)1223 203894
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Martin Bonner | Sent: 15 November 2006 10:31 | To: boost@lists.boost.org | Subject: Re: [boost] Optimized portable isnan, isfinite, | fpclassify etc | | My points are: | - I am sure there are a number of significant projects still | actively using VC6.5 | - Such projects are unlikely to want to switch to a new | version of boost. | - There is no particular reason new libraries should worry | about supporting VC6.5 and good reason not to worry about it | (it takes precious developer resource). | If it happens to work that's great, it not, tough. Very strongly agree. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Version 17 uploaded to the vault. It has passed all tests on: Win32 / VC 6.5, VC 7.1 / x86 Mac / GCC 3.3, GCC 4.0 / ppc Linux / GCC 3.3 / x86, x64, ia64, ppc, hppa, mips John, do you have time to test again? I think the problems we had last week have been fixed. --Johan
Johan Råde wrote:
John, do you have time to test again? I think the problems we had last week have been fixed.
John, If you have not tested version 17 yet, please wait until version 18. I will upload that one in a few days. Please have patience with me. This is my first attempt at designing a portable library. It has turned out to be quite a challenge. --Johan
Johan Råde wrote:
If you have not tested version 17 yet, please wait until version 18. I will upload that one in a few days.
OK, apologies, I hadn't got around to v17 yet.
Please have patience with me. This is my first attempt at designing a portable library. It has turned out to be quite a challenge.
It is a tricky area you picked ! :-) John.
John Maddock wrote:
Johan Råde wrote:
If you have not tested version 17 yet, please wait until version 18. I will upload that one in a few days.
OK, apologies, I hadn't got around to v17 yet.
There is no reason to apologize. Your help has been very valuable. --Johan
Version 18 of fpclassify has been uploaded to the vault. It has passed all tests on the following platforms: Win32 / VC 6.5, VC 7.1 / x86 Mac / GCC 3.3, GCC 4.0 / ppc Linux / GCC 3.3 / x86, x64, ia64, ppc, hppa, mips, m68k John, could you test again? I believe the problems we had last time have been fixed. --Johan
John, Do you have time to test the fpclassify library again? The the testing you did last time was very useful. (I think the tests that failed then time will pass now.) --Johan
Johan Råde wrote:
John,
Do you have time to test the fpclassify library again? The the testing you did last time was very useful. (I think the tests that failed then time will pass now.)
Well this is no fun at all, I can't break it anymore! :-) Seriously though it passes on all the platforms I can think of (and test on). I did have to add "uLL" to the end of the 64-bit constants though to get it to compile with gcc-3.4.4 on Linux/Xeon. This is a tricky one because you need uLL if uint64_t is a long long and ui64 if it's a MSVC++ specific unsigned __int64. HTH, John.
At 2:09 PM +0000 12/1/06, John Maddock wrote:
I did have to add "uLL" to the end of the 64-bit constants though to get it to compile with gcc-3.4.4 on Linux/Xeon.
This is a tricky one because you need uLL if uint64_t is a long long and ui64 if it's a MSVC++ specific unsigned __int64.
The C99 macro UINT64_C(value) might be helpful here.
Kim Barrett wrote:
At 2:09 PM +0000 12/1/06, John Maddock wrote:
I did have to add "uLL" to the end of the 64-bit constants though to get it to compile with gcc-3.4.4 on Linux/Xeon.
This is a tricky one because you need uLL if uint64_t is a long long and ui64 if it's a MSVC++ specific unsigned __int64.
The C99 macro UINT64_C(value) might be helpful here.
Indeed and we have one in boost/cstdint.hpp, but it's less useful than it first appears, because: If we are forwarding to the "native" stdint.h and someone else has already included stdint.h by the time we include it with __STDC_CONSTANT_MACROS defined, then the chances are that UINT64_C will *not be defined*. Our own version does the right thing with multiple includes, but most (all?) the native versions do not :-( John.
John Maddock wrote:
Johan Råde wrote:
John,
Do you have time to test the fpclassify library again?
[snip] it passes on all the platforms I can think of (and test on).
Great!! Thanks for your help.
I did have to add "uLL" to the end of the 64-bit constants though to get it to compile with gcc-3.4.4 on Linux/Xeon.
This is a tricky one because you need uLL if uint64_t is a long long and ui64 if it's a MSVC++ specific unsigned __int64.
I have fixed that. Now I write ((uint64_t)0x000fffff << 32) + (uint64_t)0xffffffff instead of 0x000fffffffffffff Not pretty, but it should work on all platforms that suppport uint64_t. ------------------------------ So what is left to do now? 1. Boostify the tests. (The library itself is already boostified, I think.) 2. Better documentation. 3. Formal review. Anything else? --Johan
Markus, Do you have time to test on the Alpha again? The code has changed quite a bit since you tested it. --Johan
Markus Schöpflin wrote:
Johan Råde wrote:
Do you have time to test on the Alpha again? The code has changed quite a bit since you tested it.
Give me a few days and I will try to find the time...
Thank you. I appreciate your help. --Johan
Johan Råde wrote:
Markus Schöpflin wrote:
Johan Råde wrote:
Do you have time to test on the Alpha again? The code has changed quite a bit since you tested it. Give me a few days and I will try to find the time...
Thank you. I appreciate your help.
You're welcome. Here are the results. fpclassify/test> cxx -model ansi -std strict_ansi -nopure_cname -ieee -O4 -I /vol2/boost/boost test.cpp && ./a.out fp_traits<float>::type is specialized fp_traits<double>::type is specialized fp_traits<long double>::type is generic sizeof(long double) = 16 Testing float Testing double Testing long double Seems like all tests pass. I tried with all optimization level from 0 to 4. I also tried with the command line 'cxx -D__USE_STD_IOSTREAM -O -I /vol2/boost/boost test.cpp -lm', meaning it also works in the default compiler mode (ansi, and arm object model). You can't leave out -ieee as the Alpha needs some special compiler help for conforming IEEE math handling, the processor itself is only 'mostly conformant'. Markus
Markus Schöpflin wrote:
You can't leave out -ieee as the Alpha needs some special compiler help for conforming IEEE math handling, the processor itself is only 'mostly conformant'.
What happens if you leave out -ieee? Could you run the inspect tool with -ieee leaved out? --Johan
Johan Råde wrote:
Markus Schöpflin wrote:
You can't leave out -ieee as the Alpha needs some special compiler help for conforming IEEE math handling, the processor itself is only 'mostly conformant'.
What happens if you leave out -ieee?
fpclassify/test> cxx -D__USE_STD_IOSTREAM -I /vol2/boost/boost test.cpp -lm && ./a.out fp_traits<float>::type is specialized fp_traits<double>::type is specialized fp_traits<long double>::type is generic sizeof(long double) = 16 Testing float Assertion failed: std::numeric_limits<T>::has_denorm, file test.cpp, line 100 IOT/Abort trap (core dumped)
Could you run the inspect tool with -ieee leaved out?
fpclassify/tools/inspect> cxx -D__USE_STD_IOSTREAM -I /vol2/boost/boost inspect.cpp -lm && ./a.out This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn. min 00 00 00 00 -sn. min 80 00 00 00 n. min/2 00 00 00 00 -n. min/2 00 00 00 00 n. min 00 80 00 00 1 3f 80 00 00 3/2 3f c0 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf -- -- -- -- q. nan -- -- -- -- s. nan -- -- -- -- ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn. min 00 00 00 00 00 00 00 00 -sn. min 80 00 00 00 00 00 00 00 n. min/2 00 00 00 00 00 00 00 00 -n. min/2 00 00 00 00 00 00 00 00 n. min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- q. nan -- -- -- -- -- -- -- -- s. nan -- -- -- -- -- -- -- -- ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn. min 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 -sn. min 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n. min/2 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 -n. min/2 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 n. min 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1 3f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3/2 3f ff 80 00 00 00 00 00 00 00 00 00 00 00 00 00 4/3 3f ff 55 55 55 55 55 55 55 55 55 55 55 55 55 55 max 7f fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- q. nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- s. nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Interesting! This is the first time I get the chance to test on a platform with no subnormals, no infinity and no NaN. I will have to revise the code so that this is handled correctly. (It may be that the code is correct, and it is just the tests that have to be revised.) I will investigate this. --Johan
Johan Råde wrote:
Markus Schöpflin wrote:
You can't leave out -ieee as the Alpha needs some special compiler help for conforming IEEE math handling, the processor itself is only 'mostly conformant'.
What happens if you leave out -ieee?
I forgot to add something... from the compiler man page: -ieee Support all portable features of the IEEE Standard for Binary Floating-Point Arithmetic (ANSI/IEEE Standard 754-1985), including the treatment of denormalized numbers, NaNs, infinities, and the handling of error cases. This flag also sets the _IEEE_FP macro. To flush floating point underflows to zero, add the -underflow_to_zero option. -underflow_to_zero When used with the -ieee option, directs the compiler to flush float- ing point underflows to zero. Markus
Markus Schöpflin wrote:
You can't leave out -ieee as the Alpha needs some special compiler help for conforming IEEE math handling, the processor itself is only 'mostly conformant'.
Markus, I have uploaded version 20 to the vault. Try again, without -ieee. It should work now. Also run the inspect tool, even if the tests work. --Johan
Johan Råde wrote:
I have uploaded version 20 to the vault.
Try again, without -ieee. It should work now. Also run the inspect tool, even if the tests work.
Compiler version:
cxx -V Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1B (Rev. 2650) Compiler Driver V7.1-006 (cxx) cxx Driver
OS-Version as given by uname:
uname -a OSF1 xxx V5.1 2650 alpha
Note that the official OS name is Tru64 UNIX V5.1B. Here are the results of the inspect tool: fpclassify/tools/inspect> cxx -D__USE_STD_IOSTREAM -I /vol2/boost/boost inspect.cpp -lm && ./a.out This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min -- -- -- -- -sn.min -- -- -- -- n.min/256 00 00 00 00 n.min/2 00 00 00 00 -n.min/2 00 00 00 00 n.min 00 80 00 00 1 3f 80 00 00 3/2 3f c0 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf -- -- -- -- q.nan -- -- -- -- s.nan -- -- -- -- ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 00 00 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- n.min/256 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 n.min/2 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 -n.min/2 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 n.min 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1 3f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3/2 3f ff 80 00 00 00 00 00 00 00 00 00 00 00 00 00 4/3 3f ff 55 55 55 55 55 55 55 55 55 55 55 55 55 55 max 7f fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- Here are the results of the test: fpclassify/test> cxx -D__USE_STD_IOSTREAM -I /vol2/boost/boost test.cpp -lm && ./a.out fp_traits<float>::type is specialized fp_traits<double>::type is specialized fp_traits<long double>::type is generic sizeof(long double) = 16 Testing float Testing double Testing long double Markus
Markus, Now all tests have passed, even without -ieee. Your processor is a bit odd! It does not have denorms, inifinity and NaN, except that long double does have denorms. (Look at min/2 and min/256 in the output from the inspect tool.) std::numeric_limits incorrectly states that long double does not have denorms. Fortunately my library does not use std::numeric_limits. I think now we are done. The current version (v.20) may very well become the final version. Thanks for the help. --Johan
Johan Råde wrote:
Now all tests have passed, even without -ieee.
Great.
Your processor is a bit odd! It does not have denorms, inifinity and NaN, except that long double does have denorms. (Look at min/2 and min/256 in the output from the inspect tool.)
It might be the case the the compiler has something to do with this, but I can't say for sure.
std::numeric_limits incorrectly states that long double does not have denorms. Fortunately my library does not use std::numeric_limits.
IIRC, the Alpha architecture was designed for maximum floating point speed, sacrifying some of the more exotic IEEE math features. Therefore the hardware has always relied on compiler and library help if you needed really correct IEEE math. (There were even Alpha CPUs with no floating point instructions at all, just floating point registers. All the FP math was done in software.)
I think now we are done. The current version (v.20) may very well become the final version.
Thanks for the help.
You're welcome. Markus
Markus Schöpflin wrote:
Johan Råde wrote:
Your processor is a bit odd! It does not have denorms, inifinity and NaN, except that long double does have denorms. (Look at min/2 and min/256 in the output from the inspect tool.)
It might be the case the the compiler has something to do with this, but I can't say for sure.
long double often causes trouble. I estimate that I have spent 90% of the development time for this library on getting long double to work. ;-) --Johan
Johan Rede wrote:
Your processor is a bit odd! It does not have denorms, inifinity and NaN, except that long double does have denorms. (Look at min/2 and min/256 in the output from the inspect tool.)
As Markus pointed out, it is not the processor itself: one needs to compile -ieee in order to get full support of ANSI/IEEE Standard 754-1985. For your library, compiling with cxx on Tru64 without -ieee makes little sense. Likewise, on AlphaVMS, it should be compiled /float=ieee/ieee=denorm. On iVMS, i.e. VMS on ia64, the full support for IEEE features is on by default.
std::numeric_limits incorrectly states that long double does not have denorms. Fortunately my library does not use std::numeric_limits.
Again, you need to compile with -ieee -- see below. Relatively recently, I fixed a problem with denorm_min() for std::numeric_limits<long double> for all three platforms: Tru64, AlphaVMS and iVMS. I'm not sure if the fix is in the RW library Markus is using, but if your library does not use std::numeric_limits, it is not affected by this bug.
I think now we are done. The current version (v.20) may very well become the final version.
Where can I download your library and the inspect tool from? I'd like to try it on AlphaVMS and iVMS. Thanks, Boris x.cxx ----- #include <limits> #include <stdio.h> main() { printf("%d\n", std::numeric_limits<long double>().has_denorm); } cxxosf.zko.hp.com> cxx -V Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1B (Rev. 2650) Compiler Driver V7.1-006 (cxx) cxx Driver cxxosf.zko.hp.com> cxx -ieee x.cxx && a.out 1 cxxosf.zko.hp.com> cxx x.cxx && a.out 0 cxxosf.zko.hp.com> CXXC::_3> cxx/ver HP C++ X7.3-007 for OpenVMS Alpha V7.3-2 CXXC::_3> pipe cxx/float=ieee/ieee=denorm x.cxx ; cxxl x.obj ; run x.exe 1 CXXC::_3> ICXX::_2> cxx/ver HP C++ V7.2-021 on OpenVMS IA64 V8.3 ICXX::_2> pipe cxx x.cxx ; cxxl x.obj ; run x.exe 1 ICXX::_2> ----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Wednesday, December 06, 2006 7:46 AM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Markus,
Now all tests have passed, even without -ieee.
Your processor is a bit odd! It does not have denorms, inifinity and NaN, except that long double does have denorms. (Look at min/2 and min/256 in the output from the inspect tool.)
std::numeric_limits incorrectly states that long double does not have denorms. Fortunately my library does not use std::numeric_limits.
I think now we are done. The current version (v.20) may very well become the final version.
Thanks for the help.
--Johan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
As Markus pointed out, it is not the processor itself: one needs to compile -ieee in order to get full support of ANSI/IEEE Standard 754-1985.
For your library, compiling with cxx on Tru64 without -ieee makes little sense. Likewise, on AlphaVMS, it should be compiled /float=ieee/ieee=denorm. On iVMS, i.e. VMS on ia64, the full support for IEEE features is on by default.
It should still be meaningful to use the library without -ieee. If there are no infinities and no NaNs, then the functions isinf and isnan should always return false.
Where can I download your library and the inspect tool from? I'd like to try it on AlphaVMS and iVMS.
Great! It is in the Boost Vault, http://boost-consulting.com/vault/, in the folder Math-Numerics. The file is called fpclassify.zip. Try both with and without /float=ieee/ieee=denorm, and let me know the results. --Johan
Johan Råde wrote:
Boris Gubenko wrote:
As Markus pointed out, it is not the processor itself: one needs to compile -ieee in order to get full support of ANSI/IEEE Standard 754-1985.
For your library, compiling with cxx on Tru64 without -ieee makes little sense. Likewise, on AlphaVMS, it should be compiled /float=ieee/ieee=denorm. On iVMS, i.e. VMS on ia64, the full support for IEEE features is on by default.
It should still be meaningful to use the library without -ieee. If there are no infinities and no NaNs, then the functions isinf and isnan should always return false.
Let me rephrase that: The library should produce correct results, regardless of compiler flags. Whether the library is useful or not, with certain compiler flags, is up to the user to decide. --Johan
Johan Rede wrote:
Try both with and without /float=ieee/ieee=denorm, and let me know the results.
/float=ieee is necessary on AlphaVMS because on this platform, the default floating point mode is G_FLOAT: one of so called VAX FP modes. With iVMS, we bit the bullet and made IEEE the default, although it also supports VAX FP modes. /ieee=denorm is equivalent of -ieee on Tru64 (this is the default on iVMS). It enables full support of IEEE 754-1985. /ieee=fast is equivalent of compiling on Tru64 without -ieee (this is the default on AlphaVMS). The results below are in the following order: AlphaVMS test with full IEEE support in fast IEEE mode inspect with full IEEE support in fast IEEE mode iVMS test with full IEEE support in fast IEEE mode inspect with full IEEE support in fast IEEE mode I also attached a build.com script that I used, just in case. As far as I can see, the only difference between the two platforms is -n.min/2 in fast IEEE mode for float and double: Alpha ------ float: -n.min/2 00 00 00 00 double: -n.min/2 00 00 00 00 00 00 00 00 IPF --- float: -n.min/2 80 00 00 00 double: -n.min/2 80 00 00 00 00 00 00 00 Here is the results: AlphaVMS ======== CXXC::_1> @build test HP C++ V7.1-018 for OpenVMS Alpha V7.3-2 AlphaServer 4100 5/533 4MB *** full IEEE support (as with -ieee on Tru64) fp_traits<float>::type is specialized fp_traits<double>::type is generic fp_traits<long double>::type is generic sizeof(long double) = 16 Testing float Testing double Testing long double *** fast IEEE mode (as without -ieee on Tru64) fp_traits<float>::type is specialized fp_traits<double>::type is generic fp_traits<long double>::type is generic sizeof(long double) = 16 Testing float Testing double Testing long double CXXC::_1> CXXC::_1> @build inspect HP C++ V7.1-018 for OpenVMS Alpha V7.3-2 AlphaServer 4100 5/533 4MB *** full IEEE support (as with -ieee on Tru64) This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min 00 00 00 01 -sn.min 80 00 00 01 n.min/256 00 00 80 00 n.min/2 00 40 00 00 -n.min/2 80 40 00 00 n.min 00 80 00 00 1 3f 80 00 00 3/2 3f c0 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf 7f 80 00 00 q.nan ff c0 00 00 s.nan 7f 85 55 55 ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min 00 00 00 00 00 00 00 01 -sn.min 80 00 00 00 00 00 00 01 n.min/256 00 00 10 00 00 00 00 00 n.min/2 00 08 00 00 00 00 00 00 -n.min/2 80 08 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf 7f f0 00 00 00 00 00 00 q.nan ff f8 00 00 00 00 00 00 s.nan 7f f5 55 55 55 55 55 55 ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn.min 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 -sn.min 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 n.min/256 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 n.min/2 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 -n.min/2 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 n.min 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1 3f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3/2 3f ff 80 00 00 00 00 00 00 00 00 00 00 00 00 00 4/3 3f ff 55 55 55 55 55 55 55 55 55 55 55 55 55 55 max 7f fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff inf 7f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 q.nan ff ff c0 00 00 00 00 00 00 00 00 00 00 00 00 00 s.nan 7f ff 55 55 55 55 55 55 55 55 55 55 55 55 55 55 *** fast IEEE mode (as without -ieee on Tru64) This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min -- -- -- -- -sn.min -- -- -- -- n.min/256 00 00 00 00 n.min/2 00 00 00 00 -n.min/2 00 00 00 00 n.min 00 80 00 00 1 3f 80 00 00 3/2 3f c0 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf -- -- -- -- q.nan -- -- -- -- s.nan -- -- -- -- ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 00 00 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- n.min/256 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 n.min/2 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 -n.min/2 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 n.min 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1 3f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3/2 3f ff 80 00 00 00 00 00 00 00 00 00 00 00 00 00 4/3 3f ff 55 55 55 55 55 55 55 55 55 55 55 55 55 55 max 7f fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- CXXC::_1> iVMS ==== ICXX::_1> @build test HP C++ V7.2-021 on OpenVMS IA64 V8.3 HP rx2600 (1.30GHz/3.0MB) *** full IEEE support (as with -ieee on Tru64) fp_traits<float>::type is specialized fp_traits<double>::type is generic fp_traits<long double>::type is generic sizeof(long double) = 16 Testing float Testing double Testing long double *** fast IEEE mode (as without -ieee on Tru64) fp_traits<float>::type is specialized fp_traits<double>::type is generic fp_traits<long double>::type is generic sizeof(long double) = 16 Testing float Testing double Testing long double ICXX::_1> ICXX::_1> @build inspect HP C++ V7.2-021 on OpenVMS IA64 V8.3 HP rx2600 (1.30GHz/3.0MB) *** full IEEE support (as with -ieee on Tru64) This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min 00 00 00 01 -sn.min 80 00 00 01 n.min/256 00 00 80 00 n.min/2 00 40 00 00 -n.min/2 80 40 00 00 n.min 00 80 00 00 1 3f 80 00 00 3/2 3f c0 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf 7f 80 00 00 q.nan ff c0 00 00 s.nan 7f 85 55 55 ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min 00 00 00 00 00 00 00 01 -sn.min 80 00 00 00 00 00 00 01 n.min/256 00 00 10 00 00 00 00 00 n.min/2 00 08 00 00 00 00 00 00 -n.min/2 80 08 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf 7f f0 00 00 00 00 00 00 q.nan ff f8 00 00 00 00 00 00 s.nan 7f f5 55 55 55 55 55 55 ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn.min 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 -sn.min 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 n.min/256 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 n.min/2 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 -n.min/2 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 n.min 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1 3f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3/2 3f ff 80 00 00 00 00 00 00 00 00 00 00 00 00 00 4/3 3f ff 55 55 55 55 55 55 55 55 55 55 55 55 55 55 max 7f fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff inf 7f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 q.nan ff ff c0 00 00 00 00 00 00 00 00 00 00 00 00 00 s.nan 7f ff 55 55 55 55 55 55 55 55 55 55 55 55 55 55 *** fast IEEE mode (as without -ieee on Tru64) This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min -- -- -- -- -sn.min -- -- -- -- n.min/256 00 00 00 00 n.min/2 00 00 00 00 -n.min/2 80 00 00 00 n.min 00 80 00 00 1 3f 80 00 00 3/2 3f c0 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf -- -- -- -- q.nan -- -- -- -- s.nan -- -- -- -- ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 80 00 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- n.min/256 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 n.min/2 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 -n.min/2 80 00 80 00 00 00 00 00 00 00 00 00 00 00 00 00 n.min 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1 3f ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 3/2 3f ff 80 00 00 00 00 00 00 00 00 00 00 00 00 00 4/3 3f ff 55 55 55 55 55 55 55 55 55 55 55 55 55 55 max 7f fe ff ff ff ff ff ff ff ff ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ICXX::_1> build.com --------- $ Say :== write sys$output $ if p1 .eqs. "" $ then $ Say "usage: @", f$parse(f$envir("procedure"),,,"name"), " module-name" $ exit $ endif $! $ cxx/ver $ Say f$getsyi("hw_name") $ Say "" $! $ cxx_command="cxx/float=ieee/stand=strict_ansi/nopure_cname" + - "/include=(""../"",""BOOST_BUILD_PATH/boost/"")" + - "/warning=disable=NOSTDLONGLONG" $! $ Say "*** full IEEE support (as with -ieee on Tru64)" $ pipe 'cxx_command'/ieee=denorm 'p1'.cpp ; cxxl 'p1' ; run 'p1' $ Say "*** fast IEEE mode (as without -ieee on Tru64)" $ pipe 'cxx_command'/ieee=fast 'p1'.cpp ; cxxl 'p1' ; run 'p1'
Boris Gubenko wrote:
Johan Rede wrote:
Try both with and without /float=ieee/ieee=denorm, and let me know the results.
/float=ieee is necessary on AlphaVMS because on this platform, the default floating point mode is G_FLOAT: one of so called VAX FP modes.
Interesting! I had no idea the VAX FP modes were still used. It may be overkill to try to handle the VAX FP modes. But maybe I should trigger a compile time assertion if they show up. Is there any way to detect AlphaVMS without /float=ieee at compile time?
With iVMS, we bit the bullet and made IEEE the default, although it also supports VAX FP modes.
Can you get the VAX FP modes on iVMS through compiler flags?
As far as I can see, the only difference between the two platforms is -n.min/2 in fast IEEE mode for float and double:
Alpha ------ float: -n.min/2 00 00 00 00 double: -n.min/2 00 00 00 00 00 00 00 00
= positive zero
IPF --- float: -n.min/2 80 00 00 00 double: -n.min/2 80 00 00 00 00 00 00 00
= negative zero --Johan
Johan Rede wrote:
It may be overkill to try to handle the VAX FP modes. But maybe I should trigger a compile time assertion if they show up. Is there any way to detect AlphaVMS without /float=ieee at compile time?
Yes, based on the value of __IEEE_FLOAT macro. On all the platforms: Tru64, AlphaVMS, iVMS and Linux, when IEEE floating-point mode is in effect, the cxx compiler predefines __IEEE_FLOAT macro as 1, otherwise it predefines it with a value of zero. While only VMS supports multiple floating-point modes, conditionalization below will be correct for all the platforms the cxx compiler supports: #if defined(__DECCXX) && !__IEEE_FLOAT # VAX FP mode #endif Or you can explicitly conditionalize for VMS: #if defined(__DECCXX) && defined(__vms) && !__IEEE_FLOAT # VAX FP mode #endif
Can you get the VAX FP modes on iVMS through compiler flags?
Yes: /float=g_float and /float=d_float.
Alpha ------ float: -n.min/2 00 00 00 00 double: -n.min/2 00 00 00 00 00 00 00 00
= positive zero
IPF --- float: -n.min/2 80 00 00 00 double: -n.min/2 80 00 00 00 00 00 00 00
= negative zero
Does it represent a problem on either platform or this is implementation-defined?
Wait, I'm a bit confused. Are you telling me that the Itanium processor supports the VAX FP modes?
No, it does not.
Or is the VAX FP support done through software? Wouldn't that be very slow?
It is software emulation which is, obviously, slower than native IEEE, but I don't have performance numbers at hand. We encourage customers to use IEEE on both Alpha and Itanium. On Alpha, most C++ customers are still using G_FLOAT, the default, but after the IA64 port, there is a real push to use IEEE on both platforms, especially in mixed-architecture environment.
The VAX FP modes do not support denormals, infinity and NaN, right?
Right.
We just need to able to detect the VAX FP modes at compile time.
In VAX FP modes, __IEEE_FLOAT macro is defined as zero. Btw, there is another macro which can be used to distinguish between full IEEE support (-ieee on Tru64 and /ieee=denorm on VMS) and fast IEEE mode (which does not have NaNs and Infinity). This macro is _IEEE_FP which is defined when IEEE support is enabled and not defined otherwise. Based on the results I posted yesterday, is it correct to say that fpclassify library passes the tests on both VMS platforms? Thanks, Boris
Boris Gubenko wrote:
While only VMS supports multiple floating-point modes, conditionalization below will be correct for all the platforms the cxx compiler supports:
#if defined(__DECCXX) && !__IEEE_FLOAT # VAX FP mode #endif
Then I should be able to add code that handles the VAX FP modes. Do both platforms support uint64_t? How is long double implemented in the VAX FP mode? Is it the same as double, or does it have more than 8 bytes? How does the sign bit work in the VAX FP mode? Is it the leading bit of the leading byte? Do you reverse the sign of a number simply by flipping the sign bit?
Alpha ------ float: -n.min/2 00 00 00 00 double: -n.min/2 00 00 00 00 00 00 00 00 = positive zero
IPF --- float: -n.min/2 80 00 00 00 double: -n.min/2 80 00 00 00 00 00 00 00 = negative zero
Does it represent a problem on either platform or this is implementation-defined?
For practical purposes it can't be a problem. Positive and negative zero are really the same number. I'm not an expert on floating point arithmetic and IEEE 754 standard, so I can't give you a better answer than that.
Based on the results I posted yesterday, is it correct to say that fpclassify library passes the tests on both VMS platforms?
That is correct. It has passed all tests on both VMS platforms, in both full ieee mode and fast ieee mode. --Johan
Johan Rede wrote:
Do both platforms support uint64_t?
No, they support __int64 and long long. uint64_t can be typedef'ed as unsigned __int64 or unsigned long long.
How is long double implemented in the VAX FP mode? Is it the same as double, or does it have more than 8 bytes?
On Tru64 and AlphaVMS (in both VAX FP modes and IEEE), there are two types of long double: 128-bit long double and 64-bit long double. iVMS supports only 128-bit double. On Tru64 V5.0 and later, 128-bit long double is the default, but 64-bit long double can be requested by compiling with -long_double_size 64 switch. On VMS, it would be /l_double_size=[64,128] switch, but the default on VMS has always been 128-bit long double. When /l_double_size=64 is specified on iVMS, the compiler issues a warning and ignores the option. The 64-bit long double is rarely used nowadays and this is why we have dropped it for iVMS. I think, it would be completely reasonable if your library asserts if the code was compiled for 64-bit long double. You can recognize this case by checking the __X_FLOAT macro: for 64-bit long double it is predefined as 0, otherwise, it is predefined as 1.
How does the sign bit work in the VAX FP mode? Is it the leading bit of the leading byte? Do you reverse the sign of a number simply by flipping the sign bit?
The thing is that, while internal representation of (deprecated) 64-bit long double depends on the floating-point mode, for 128-bit long double, the internal representation is the same in all FP modes. If you want to support VAX FP modes, this is another reason to support only 128-bit long double across the board.
Based on the results I posted yesterday, is it correct to say that fpclassify library passes the tests on both VMS platforms?
That is correct. It has passed all tests on both VMS platforms, in both full ieee mode and fast ieee mode.
This is good!
Could you run the attached version of the inspect tool on both platforms in VAX FP mode.
Attached results in the following order: AlphaVMS G_FLOAT D_FLOAT iVMS G_FLOAT D_FLOAT AlphaVMS ======== CXXC::_5> @build inspect HP C++ V7.1-018 for OpenVMS Alpha V7.3-2 AlphaServer 4100 5/533 4MB *** G_FLOAT This platform is big-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min -- -- -- -- -sn.min -- -- -- -- n.min/256 00 00 00 00 n.min/2 00 00 00 00 -n.min/2 00 00 00 00 n.min 80 00 00 00 1 80 40 00 00 3/4 40 40 00 00 4/3 aa 40 ab aa max ff 7f ff ff inf -- -- -- -- q.nan -- -- -- -- s.nan -- -- -- -- ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 00 00 00 00 00 00 00 00 n.min 10 00 00 00 00 00 00 00 1 10 40 00 00 00 00 00 00 3/4 08 40 00 00 00 00 00 00 4/3 15 40 55 55 55 55 55 55 max ff 7f ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 n.min/2 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 -n.min/2 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 80 n.min 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 3f 3/4 00 00 00 00 00 00 00 00 00 00 00 00 00 80 fe 3f 4/3 55 55 55 55 55 55 55 55 55 55 55 55 55 55 ff 3f max ff ff ff ff ff ff ff ff ff ff ff ff ff ff fe 7f inf -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- *** D_FLOAT This platform is big-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min -- -- -- -- -sn.min -- -- -- -- n.min/256 00 00 00 00 n.min/2 00 00 00 00 -n.min/2 00 00 00 00 n.min 80 00 00 00 1 80 40 00 00 3/4 40 40 00 00 4/3 aa 40 ab aa max ff 7f ff ff inf -- -- -- -- q.nan -- -- -- -- s.nan -- -- -- -- ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 00 00 00 00 00 00 00 00 n.min 80 00 00 00 00 00 00 00 1 80 40 00 00 00 00 00 00 3/4 40 40 00 00 00 00 00 00 4/3 aa 40 aa aa aa aa a8 aa max ff 7f ff ff ff ff f8 ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 n.min/2 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 -n.min/2 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 80 n.min 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 3f 3/4 00 00 00 00 00 00 00 00 00 00 00 00 00 80 fe 3f 4/3 55 55 55 55 55 55 55 55 55 55 55 55 55 55 ff 3f max ff ff ff ff ff ff ff ff ff ff ff ff ff ff fe 7f inf -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- CXXC::_5> iVMS ==== ICXX::_2> @build inspect HP C++ V7.2-021 on OpenVMS IA64 V8.3 HP rx2600 (1.30GHz/3.0MB) *** G_FLOAT This platform is big-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min -- -- -- -- -sn.min -- -- -- -- n.min/256 00 00 00 00 n.min/2 00 00 00 00 -n.min/2 00 00 00 00 n.min 80 00 00 00 1 80 40 00 00 3/4 40 40 00 00 4/3 aa 40 ab aa max ff 7f ff ff inf -- -- -- -- q.nan -- -- -- -- s.nan -- -- -- -- ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 00 00 00 00 00 00 00 00 n.min 10 00 00 00 00 00 00 00 1 10 40 00 00 00 00 00 00 3/4 08 40 00 00 00 00 00 00 4/3 15 40 55 55 55 55 55 55 max ff 7f ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 n.min/2 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 -n.min/2 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 80 n.min 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 3f 3/4 00 00 00 00 00 00 00 00 00 00 00 00 00 80 fe 3f 4/3 55 55 55 55 55 55 55 55 55 55 55 55 55 55 ff 3f max ff ff ff ff ff ff ff ff ff ff ff ff ff ff fe 7f inf -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- *** D_FLOAT This platform is big-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min -- -- -- -- -sn.min -- -- -- -- n.min/256 00 00 00 00 n.min/2 00 00 00 00 -n.min/2 00 00 00 00 n.min 80 00 00 00 1 80 40 00 00 3/4 40 40 00 00 4/3 aa 40 ab aa max ff 7f ff ff inf -- -- -- -- q.nan -- -- -- -- s.nan -- -- -- -- ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 00 00 00 00 00 00 00 00 n.min 80 00 00 00 00 00 00 00 1 80 40 00 00 00 00 00 00 3/4 40 40 00 00 00 00 00 00 4/3 aa 40 aa aa aa aa a8 aa max ff 7f ff ff ff ff f8 ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- ---------- long double -------------- 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 n.min/2 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 -n.min/2 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 80 n.min 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 1 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 3f 3/4 00 00 00 00 00 00 00 00 00 00 00 00 00 80 fe 3f 4/3 55 55 55 55 55 55 55 55 55 55 55 55 55 55 ff 3f max ff ff ff ff ff ff ff ff ff ff ff ff ff ff fe 7f inf -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- ICXX::_2>
Boris, I have uploaded an experimental version called fpclassify_non_ieee.zip. Could you test it in VAX FP mode? --Johan
Johan,
Could you test it in VAX FP mode?
will do later today. -boris ----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Friday, December 08, 2006 3:11 PM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Boris,
I have uploaded an experimental version called fpclassify_non_ieee.zip.
Could you test it in VAX FP mode?
--Johan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have had second thoughts about this matter, and I have decided not to support the non-ieee mode. Instead I will do a compile time assert. The problem is that in the non-ieee mode, float and double use a VAX FP format without denormals, while long double uses an IEEE extended double precision format with denormals. Dealing with this is not that difficult, but it would make the code more complex, and you are encouraging your customers to use the ieee mode anyway. I don't think it is worth the trouble. --Johan Boris Gubenko wrote:
Johan,
Could you test it in VAX FP mode?
will do later today.
-boris
----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Friday, December 08, 2006 3:11 PM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Boris,
I have uploaded an experimental version called fpclassify_non_ieee.zip.
Could you test it in VAX FP mode?
--Johan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Johan Rede wrote:
I don't think it is worth the trouble.
I agree. If you don't support VAX FP mode, then 64-bit long double is "automatically" supported and there is no need to check __X_FLOAT macro. To verify it, I ran the test and the inspect tool on AlphaVMS and Tru64 with 64-bit long double and, as far as I can see, the results are correct. Attached results in the following order: AlphaVMS test full IEEE support fast IEEE mode inspect full IEEE support fast IEEE mode Tru64 full IEEE support test inspect fast IEEE mode test inspect AlphaVMS ======== CXXC::_3> @build test HP C++ V7.1-018 for OpenVMS Alpha V7.3-2 AlphaServer 4100 5/533 4MB *** full IEEE support, 64-bit long double fp_traits<float>::type is specialized fp_traits<double>::type is generic fp_traits<long double>::type is generic sizeof(long double) = 8 Testing float Testing double Testing long double *** fast IEEE mode, 64-bit long double fp_traits<float>::type is specialized fp_traits<double>::type is generic fp_traits<long double>::type is generic sizeof(long double) = 8 Testing float Testing double Testing long double CXXC::_3> CXXC::_3> @build inspect HP C++ V7.1-018 for OpenVMS Alpha V7.3-2 AlphaServer 4100 5/533 4MB *** full IEEE support, 64-bit long double This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min 00 00 00 01 -sn.min 80 00 00 01 n.min/256 00 00 80 00 n.min/2 00 40 00 00 -n.min/2 80 40 00 00 n.min 00 80 00 00 1 3f 80 00 00 3/2 3f c0 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf 7f 80 00 00 q.nan ff c0 00 00 s.nan 7f 85 55 55 ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min 00 00 00 00 00 00 00 01 -sn.min 80 00 00 00 00 00 00 01 n.min/256 00 00 10 00 00 00 00 00 n.min/2 00 08 00 00 00 00 00 00 -n.min/2 80 08 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf 7f f0 00 00 00 00 00 00 q.nan ff f8 00 00 00 00 00 00 s.nan 7f f5 55 55 55 55 55 55 ---------- long double -------------- 0 00 00 00 00 00 00 00 00 sn.min 00 00 00 00 00 00 00 01 -sn.min 80 00 00 00 00 00 00 01 n.min/256 00 00 10 00 00 00 00 00 n.min/2 00 08 00 00 00 00 00 00 -n.min/2 80 08 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf 7f f0 00 00 00 00 00 00 q.nan ff f8 00 00 00 00 00 00 s.nan 7f f5 55 55 55 55 55 55 *** fast IEEE mode, 64-bit long double This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min -- -- -- -- -sn.min -- -- -- -- n.min/256 00 00 00 00 n.min/2 00 00 00 00 -n.min/2 00 00 00 00 n.min 00 80 00 00 1 3f 80 00 00 3/2 3f c0 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf -- -- -- -- q.nan -- -- -- -- s.nan -- -- -- -- ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 00 00 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- ---------- long double -------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 00 00 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- CXXC::_3> Tru64 ===== cxxosf.zko.hp.com> cxx -V Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1B (Rev. 2650) Compiler Driver V7.1-006 (cxx) cxx Driver cxxosf.zko.hp.com> /usr/sbin/sizer -c cpu "DEC4100" cxxosf.zko.hp.com> With -ieee ---------- cxxosf.zko.hp.com> test.out fp_traits<float>::type is specialized fp_traits<double>::type is specialized fp_traits<long double>::type is specialized sizeof(long double) = 8 Testing float Testing double Testing long double cxxosf.zko.hp.com> cxxosf.zko.hp.com> inspect.out This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min 00 00 00 01 -sn.min 80 00 00 01 n.min/256 00 00 80 00 n.min/2 00 40 00 00 -n.min/2 80 40 00 00 n.min 00 80 00 00 1 3f 80 00 00 3/2 3f c0 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf 7f 80 00 00 q.nan ff c0 00 00 s.nan 7f 85 55 55 ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min 00 00 00 00 00 00 00 01 -sn.min 80 00 00 00 00 00 00 01 n.min/256 00 00 10 00 00 00 00 00 n.min/2 00 08 00 00 00 00 00 00 -n.min/2 80 08 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf 7f f0 00 00 00 00 00 00 q.nan ff f8 00 00 00 00 00 00 s.nan 7f f5 55 55 55 55 55 55 ---------- long double -------------- 0 00 00 00 00 00 00 00 00 sn.min 00 00 00 00 00 00 00 01 -sn.min 80 00 00 00 00 00 00 01 n.min/256 00 00 10 00 00 00 00 00 n.min/2 00 08 00 00 00 00 00 00 -n.min/2 80 08 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf 7f f0 00 00 00 00 00 00 q.nan ff f8 00 00 00 00 00 00 s.nan 7f f5 55 55 55 55 55 55 cxxosf.zko.hp.com> Without -ieee ------------- cxxosf.zko.hp.com> test.out fp_traits<float>::type is specialized fp_traits<double>::type is specialized fp_traits<long double>::type is specialized sizeof(long double) = 8 Testing float Testing double Testing long double cxxosf.zko.hp.com> cxxosf.zko.hp.com> inspect.out This platform is little-endian. BOOST_LITTTLE_ENDIAN is defined. ---------- float -------------------- 0 00 00 00 00 sn.min -- -- -- -- -sn.min -- -- -- -- n.min/256 00 00 00 00 n.min/2 00 00 00 00 -n.min/2 00 00 00 00 n.min 00 80 00 00 1 3f 80 00 00 3/2 3f c0 00 00 4/3 3f aa aa ab max 7f 7f ff ff inf -- -- -- -- q.nan -- -- -- -- s.nan -- -- -- -- ---------- double ------------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 00 00 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- ---------- long double -------------- 0 00 00 00 00 00 00 00 00 sn.min -- -- -- -- -- -- -- -- -sn.min -- -- -- -- -- -- -- -- n.min/256 00 00 00 00 00 00 00 00 n.min/2 00 00 00 00 00 00 00 00 -n.min/2 00 00 00 00 00 00 00 00 n.min 00 10 00 00 00 00 00 00 1 3f f0 00 00 00 00 00 00 3/2 3f f8 00 00 00 00 00 00 4/3 3f f5 55 55 55 55 55 55 max 7f ef ff ff ff ff ff ff inf -- -- -- -- -- -- -- -- q.nan -- -- -- -- -- -- -- -- s.nan -- -- -- -- -- -- -- -- cxxosf.zko.hp.com> ----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Friday, December 08, 2006 4:37 PM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc I have had second thoughts about this matter, and I have decided not to support the non-ieee mode. Instead I will do a compile time assert. The problem is that in the non-ieee mode, float and double use a VAX FP format without denormals, while long double uses an IEEE extended double precision format with denormals. Dealing with this is not that difficult, but it would make the code more complex, and you are encouraging your customers to use the ieee mode anyway. I don't think it is worth the trouble. --Johan Boris Gubenko wrote:
Johan,
Could you test it in VAX FP mode?
will do later today.
-boris
----- Original Message ----- From: "Johan Råde" <rade@maths.lth.se> To: <boost@lists.boost.org> Sent: Friday, December 08, 2006 3:11 PM Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
Boris,
I have uploaded an experimental version called fpclassify_non_ieee.zip.
Could you test it in VAX FP mode?
--Johan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boris Gubenko wrote:
Johan Rede wrote:
I don't think it is worth the trouble.
I agree.
If you don't support VAX FP mode, then 64-bit long double is "automatically" supported and there is no need to check __X_FLOAT macro.
To verify it, I ran the test and the inspect tool on AlphaVMS and Tru64 with 64-bit long double and, as far as I can see, the results are correct.
Attached results in the following order:
AlphaVMS test full IEEE support fast IEEE mode inspect full IEEE support fast IEEE mode Tru64 full IEEE support test inspect fast IEEE mode test inspect
Everything looks fine. Which platforms have you tested on now? Is this list correct? VMS / HP C++ 7.1 / alpha, ia64 (ieee fp mode, not vax fp mode) Tru64 / Compaq C++ 7.1 / alpha Is HP C++ the same compiler as aCC? --Johan
Johan Rede wrote:
Everything looks fine.
Great!
Which platforms have you tested on now? Is this list correct?
VMS / HP C++ 7.1 / alpha, ia64 (ieee fp mode, not vax fp mode) Tru64 / Compaq C++ 7.1 / alpha
To be precise, On VMS/ia64, it was HP C++ 7.2, but it does not matter for your library.
Is HP C++ the same compiler as aCC?
aCC is the name of HP C++ compiler for HP-UX, both ia64 and PA-RISC. The compiler identification macro is __HP_aCC. cxx is the name of HP C++ compiler for Tru64 and VMS: both AlphaVMS and VMS/ia64. The compiler identification macro is __DECCXX. For Tru64, the compiler was not rebranded as HP C++ compiler and remains "Compaq C++". In reality, both AlphaVMS and Tru64 compilers were developed by DEC, hence __DECCXX macro. For iVMS, when the development started, DEC was already Compaq, now HP :-) Boris
Boris Gubenko wrote:
aCC is the name of HP C++ compiler for HP-UX, both ia64 and PA-RISC. The compiler identification macro is __HP_aCC.
cxx is the name of HP C++ compiler for Tru64 and VMS: both AlphaVMS and VMS/ia64. The compiler identification macro is __DECCXX.
For Tru64, the compiler was not rebranded as HP C++ compiler and remains "Compaq C++". In reality, both AlphaVMS and Tru64 compilers were developed by DEC, hence __DECCXX macro. For iVMS, when the development started, DEC was already Compaq, now HP :-)
Boris
Is the following description correct: "The library has been tested on the following platforms: ... Tru64 / Compaq C++ 7.1 / alpha (in IEEE floating point mode) VMS / HP C++ 7.1 / alpha (in IEEE floating point mode) VMS / HP C++ 7.2 / ia64 (in IEEE floating point mode) The library does not support the VAX floating point mode on Tru64 / Compaq C++ and VMS / HP C++." --Johan
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Johan Rede wrote:
Is the following description correct:
"The library has been tested on the following platforms:
... Tru64 / Compaq C++ 7.1 / alpha (in IEEE floating point mode) VMS / HP C++ 7.1 / alpha (in IEEE floating point mode) VMS / HP C++ 7.2 / ia64 (in IEEE floating point mode)
The library does not support the VAX floating point mode on Tru64 / Compaq C++ and VMS / HP C++."
Tru64, like most of other platforms, does not support any floating point mode other than IEEE. For this platform, "(in IEEE floating point mode)" is reduntant. This is how I'd describe it: "The library has been tested on the following platforms: ... Tru64 / Compaq C++ 7.1 / alpha VMS / HP C++ 7.1 / alpha (in IEEE floating point mode) VMS / HP C++ 7.2 / ia64 (in IEEE floating point mode) The library does not support the VAX floating point mode on VMS." Thanks, Boris
Boris Gubenko wrote:
This is how I'd describe it:
"The library has been tested on the following platforms: ... Tru64 / Compaq C++ 7.1 / alpha VMS / HP C++ 7.1 / alpha (in IEEE floating point mode) VMS / HP C++ 7.2 / ia64 (in IEEE floating point mode)
The library does not support the VAX floating point mode on VMS."
Thanks for the information. --Johan
Version 21 has been uploaded to the vault. It has passed all tests on the following platforms: Win32 / MSVC 6.5, 7.1 / x86 Win32 / Intel C++ 7.1, 8.1, 9.1 / x86 Mac OS X / GCC 3.3, 4.0 / ppc Linux / Intel C++ 9.1 / x86, ia64 Linux / GCC 3.3 / x86, x64, ia64, ppc, hppa, mips, m68k Linux / GCC 3.4 / x64 HP-UX / aCC, GCC 4.1 / ia64 HP-UX / aCC / hppa Tru64 / Compaq C++ 7.1 / alpha VMS / HP C++ 7.1 / alpha (in IEEE floating point mode) VMS / HP C++ 7.2 / ia64 (in IEEE floating point mode) It does not support the VAX floating point mode on VMS. --Johan
Version 22 has been uploaded to the vault (in the folder Math-Numerics) New stuff: 1. Fixed linking problem 2. Improved documentation 3. Has been merged with the nonfinite_num_facets library (Facets for portable handling of infinity and NaN in text streams) 4. The facets should now detect NaN reliably on all platforms 5. The facets have been moved from namespace boost::io to boost::math --Johan
Boris Gubenko wrote:
If you don't support VAX FP mode, then 64-bit long double is "automatically" supported and there is no need to check __X_FLOAT macro.
The library supports several (5 to be exact) formats for long double, so that is not an issue. --Johan
Boris, Could you run the attached version of the inspect tool on both platforms in VAX FP mode. --Johan // inspect.cpp // Copyright (c) 2006 Johan Rade // Distributed under the Boost Software License, Version 1.0. // (See accompanying file LICENSE_1_0.txt // or copy at http://www.boost.org/LICENSE_1_0.txt) //------------------------------------- #include <iomanip> #include <iostream> #include <limits> #include <boost/detail/endian.hpp> //------------------------------------------------------------------------------ template<class T> void print(const char* s, T x, bool ok = true); template<class T> void print(); inline bool is_big_endian() { float x = 1.0f; unsigned char first_byte = *reinterpret_cast<unsigned char*>(&x); return first_byte != 0; } //------------------------------------------------------------------------------ int main() { std::cout << '\n'; if(is_big_endian()) std::cout << "This platform is big-endian.\n"; else std::cout << "This platform is little-endian.\n"; #ifdef BOOST_BIG_ENDIAN std::cout << "BOOST_BIG_ENDIAN is defined.\n\n"; #endif #if defined BOOST_LITTLE_ENDIAN std::cout << "BOOST_LITTTLE_ENDIAN is defined.\n\n"; #endif std::cout << "---------- float --------------------\n\n"; print<float>(); std::cout << "---------- double -------------------\n\n"; print<double>(); std::cout << "---------- long double --------------\n\n"; print<long double>(); return 0; } //------------------------------------------------------------------------------ template<class T> void print(const char* s, T x, bool ok) { std::cout << std::left << std::setw(10) << s << std::right; std::cout << std::hex << std::setfill('0'); if(ok) { if(is_big_endian()) { for(int i = 0; i < (int)sizeof(T); ++i) std::cout << std::setw(2) << (unsigned int)*((unsigned char*)&x + i) << ' '; } else { for(int i = sizeof(T) - 1; i >= 0; --i) std::cout << std::setw(2) << (unsigned int)*((unsigned char*)&x + i) << ' '; } } else { for(int i = 0; i < (int)sizeof(T); ++i) std::cout << "-- "; } std::cout << '\n'; std::cout << std::dec << std::setfill(' '); } template<class T> void print() { print("0", (T)0); print("sn.min", std::numeric_limits<T>::denorm_min(), std::numeric_limits<T>::has_denorm); print("-sn.min", -std::numeric_limits<T>::denorm_min(), std::numeric_limits<T>::has_denorm); print("n.min/256", (std::numeric_limits<T>::min)()/256); print("n.min/2", (std::numeric_limits<T>::min)()/2); print("-n.min/2", -(std::numeric_limits<T>::min)()/2); print("n.min", (std::numeric_limits<T>::min)()); print("1", (T)1); print("3/4", (T)3/(T)4); print("4/3", (T)4/(T)3); print("max", (std::numeric_limits<T>::max)()); print("inf", std::numeric_limits<T>::infinity(), std::numeric_limits<T>::has_infinity); print("q.nan", std::numeric_limits<T>::quiet_NaN(), std::numeric_limits<T>::has_quiet_NaN); print("s.nan", std::numeric_limits<T>::signaling_NaN(), std::numeric_limits<T>::has_signaling_NaN); std::cout << "\n\n"; }
Boris Gubenko wrote:
With iVMS, we bit the bullet and made IEEE the default, although it also supports VAX FP modes.
Wait, I'm a bit confused. Are you telling me that the Itanium processor supports the VAX FP modes? Or is the VAX FP support done through software? Wouldn't that be very slow? Am I missing something? --Johan
Boris Gubenko wrote:
/float=ieee is necessary on AlphaVMS because on this platform, the default floating point mode is G_FLOAT: one of so called VAX FP modes.
The VAX FP modes do not support denormals, infinity and NaN, right? If that is the case, then we can implement fpclassify as follows: return x ? FP_NORMAL : FP_ZERO; We just need to able to detect the VAX FP modes at compile time. --Johan
Markus, Just for my records, what O/S and compiler are you using? --Johan
John Maddock wrote:
Seriously though it passes on all the platforms I can think of (and test on).
John, Which platforms did you test on? Is this list correct? Win32 / Intel 7, Intel 8, Intel 9.1 / x86 Linux / Intel 9.1 / x86, ia64 Linux / GCC 3.3.4 / x64 HP-UX / aCC, GCC / ia64 --Johan
Johan Råde wrote:
John Maddock wrote:
Seriously though it passes on all the platforms I can think of (and test on).
John,
Which platforms did you test on?
Is this list correct?
Win32 / Intel 7, Intel 8, Intel 9.1 / x86 Linux / Intel 9.1 / x86, ia64 Linux / GCC 3.3.4 / x64 HP-UX / aCC, GCC / ia64
Yep, you can add HP-UX / aCC / PA_RISC to the list as well. John.
John Maddock wrote:
Johan Råde wrote:
John Maddock wrote:
Seriously though it passes on all the platforms I can think of (and test on). John,
Which platforms did you test on?
Is this list correct?
Win32 / Intel 7, Intel 8, Intel 9.1 / x86 Linux / Intel 9.1 / x86, ia64 Linux / GCC 3.3.4 / x64 HP-UX / aCC, GCC / ia64
Yep, you can add HP-UX / aCC / PA_RISC to the list as well.
John.
Impressive! You have spared no effort. Without people like you, this library would not be possible. I may be a bit pedantic, but could you fill in the missing compiler version numbers? Win32 / Intel 7.?, Intel 8.? / x86 HP-UX / aCC?, GCC? / ia64 HP-UX / aCC? / PA_RISC --Johan
Johan Råde wrote:
John Maddock wrote:
Johan Råde wrote:
John Maddock wrote:
Seriously though it passes on all the platforms I can think of (and test on). John,
Which platforms did you test on?
Is this list correct?
Win32 / Intel 7, Intel 8, Intel 9.1 / x86 Linux / Intel 9.1 / x86, ia64 Linux / GCC 3.3.4 / x64 HP-UX / aCC, GCC / ia64
Yep, you can add HP-UX / aCC / PA_RISC to the list as well.
John.
Impressive! You have spared no effort. Without people like you, this library would not be possible.
I may be a bit pedantic, but could you fill in the missing compiler version numbers?
Win32 / Intel 7.?, Intel 8.? / x86 HP-UX / aCC?, GCC? / ia64 HP-UX / aCC? / PA_RISC
Intel(R) C++ Compiler for 32-bit applications, Version 7.1 Build 0040309Z Intel(R) C++ Compiler for 32-bit applications, Version 8.1 Build 20060606Z Package ID: w_cc_pc_8.1.038 PA-RISK: HP-UX td191 B.11.23 U 9000/800 1294588977 unlimited-user license aCC: HP ANSI C++ B3910B A.03.73 Itanium: HP-UX td176 B.11.23 U ia64 1928826293 unlimited-user license aCC: HP C/aC++ B3910B A.06.12 [Aug 17 2006] Using built-in specs. Target: ia64-hp-hpux11.23 Configured with: /tmp/gcc-4.1.0.tar.gz/gcc-4.1.0/configure --host=ia64-hp-hpux11 .23 --target=ia64-hp-hpux11.23 --build=ia64-hp-hpux11.23 --prefix=/opt/hp-gcc-4. 1.0 --enable-languages=c,c++ --with-gnu-as --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-threads=posix Thread model: posix gcc version 4.1.0 John.
The fpclasify library (v.20) has now passed all tests on the following platforms: Win32 / VC 6.5, VC 7.1 / x86 Win32 / Intel 7.1, Intel 8.1, Intel 9.1 / x86 Linux / Intel 9.1 / x86, ia64 Linux / GCC 3.3 / x86, x64, ia64, ppc, hppa, mips, m68k Linux / GCC 3.4 / x64 HP-UX / aCC, GCC 4.1 / ia64 HP-UX / aCC / hppa Tru64 Unix / Compaq 7.1 / alpha Mac OS-X / GCC 3.3, GCC 4.0 / ppc Many thanks to Håkan Ardö, John Maddock, Markus Schöpflin and Olivier Verdier who have done the tests. --Johan
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Johan Råde Sent: 06 December 2006 15:01 To: boost@lists.boost.org Subject: Re: [boost] Optimized portable isnan, isfinite, fpclassify etc
The fpclasify library (v.20) has now passed all tests on the following platforms:
Win32 / VC 6.5, VC 7.1 / x86 Win32 / Intel 7.1, Intel 8.1, Intel 9.1 / x86 Linux / Intel 9.1 / x86, ia64 Linux / GCC 3.3 / x86, x64, ia64, ppc, hppa, mips, m68k Linux / GCC 3.4 / x64 HP-UX / aCC, GCC 4.1 / ia64 HP-UX / aCC / hppa Tru64 Unix / Compaq 7.1 / alpha Mac OS-X / GCC 3.3, GCC 4.0 / ppc
Many thanks to Håkan Ardö, John Maddock, Markus Schöpflin and Olivier Verdier who have done the tests.
And Johan deserves a medal for his commendably dogged pursuit of something that would have not have been a problem if the Standard had specified things just a little more fully - a lesson that should be learnt. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
participants (7)
-
Boris Gubenko -
Johan Råde -
John Maddock -
Kim Barrett -
Markus Schöpflin -
Martin Bonner -
Paul A Bristow