Re: [boost] [serialization] facets for non-finite numbers
I have uploaded a new version to the vault. This version features: 1. Strict C99 conformance: Output is consistent with C99. (In particular, negative NaN is written as "-nan". All representations allowed by C99 are recognized as input. 2. Optional support for negative 0. 3. Clean build with VC++ 7.1 at warning level 4. 4. Improved documentation. This version is backwards compatible with earlier versions. The code comes with a test program. I have only run the test program on VC++ 7.1. If you run the test program on any other platform, please report the result to me. Both good and bad results are of interest. Many thanks to Paul Bristow, John Maddock and Gennaro Prota for valauble comments. --Johan Råde Johan Råde wrote:
----- The Problem -----
The C++98 standard does not specify how non-finite floating point numbers, such as infinity and not-a-number, should be represented in text streams. As a result, different platforms use different representations. This can cause undefined behavior when text files and serialization archives are moved between different platforms.
Some platforms can not even read their own output! For instance, the following test fails with VC++ 7.1:
stringstream s; double x = numeric_limits<double>::infinity(); double y; ss << x; ss >> y; assert(x == y);
----- The Solution -----
The facets extended_num_put and extended_num_get write and read non-finite floating point numbers to text streams in a consistent and portable manner.
The following test succeeds with VC++ 7.1:
stringstream s; locale old_locale; locale tmp_locale(old_locale, new extended_num_put<char>); locale new_locale(tmp_locale, new extended_num_get<char>); s.imbue(new_locale);
double x = numeric_limits<double>::infinity(); double y; ss << x; ss >> y; assert(x == y);
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Johan Råde | Sent: 03 August 2006 09:54 | To: boost@lists.boost.org | Subject: Re: [boost] [serialization] facets for non-finite numbers | | I have uploaded a new version to the vault. | | This version features: | | 1. Strict C99 conformance: | Output is consistent with C99. (In particular, | negative NaN is | written as "-nan". | All representations allowed by C99 are recognized as input. | | 2. Optional support for negative 0. | | 3. Clean build with VC++ 7.1 at warning level 4. | | 4. Improved documentation. | | This version is backwards compatible with earlier versions. | | The code comes with a test program. I have only run the test | program on | VC++ 7.1. | If you run the test program on any other platform, please report the | result to me. | Both good and bad results are of interest. | | Many thanks to Paul Bristow, John Maddock and Gennaro Prota | for valauble comments. This compiles and run OK on MSVC 8.0 after automatic conversion of the 7.1 vcproject. No warnings either :-)) But of course, the proof of portability is other endians and layouts etc :-) I have yet to get my head round predicting if it will work but looks rather plausible. The only final requirement for TR1 is to template it to provide template<class T> bool signbit(T x); Additions I can see are checks for: 1 If T not specialized then I returning false may be the obvious option. But John Maddock's prototype real_concept is NOT specialised, and yet it would be nice if signbit worked with real_concept. It would also be nice if it worked with NTL quad_float (also == Darwin long double and doubledouble) and RR types, and big_integer when we get one. I will have to think about this. 2 If is_specialized nad is_signed == false, (all unsigned types) then we must surely return false. So many thanks to you for your valuable work on this. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
New version uploaded to the vault, with 1. More documentation 2. Documentation in HTML format 3. Regression tests written with the Boost.Test library Where should the code live, if accepted into Boost? The serialization library is not the right home. I would suggest the boost.math library. This is a already a collection of unrelated sub-libraries, such as quaternion, special functions and greatest common divisor. --Johan Råde Johan Råde wrote:
----- The Problem -----
The C++98 standard does not specify how non-finite floating point numbers, such as infinity and not-a-number, should be represented in text streams. As a result, different platforms use different representations. This can cause undefined behavior when text files and serialization archives are moved between different platforms.
Some platforms can not even read their own output! For instance, the following test fails with VC++ 7.1:
stringstream s; double x = numeric_limits<double>::infinity(); double y; ss << x; ss >> y; assert(x == y);
----- The Solution -----
The facets extended_num_put and extended_num_get write and read non-finite floating point numbers to text streams in a consistent and portable manner.
The following test succeeds with VC++ 7.1:
stringstream s; locale old_locale; locale tmp_locale(old_locale, new extended_num_put<char>); locale new_locale(tmp_locale, new extended_num_get<char>); s.imbue(new_locale);
double x = numeric_limits<double>::infinity(); double y; ss << x; ss >> y; assert(x == y);
Looks good and we NEED it in Boost so that both lexical cast and serialization work right. signbit and isnan should go in Boost TR1? Not sure about the rest. But an attempt to check is compiles with MSVC 8.0 failed - missing .\c99_test.cpp in zip? And something wrong in archive_test? Suggestions? Paul PS A confirmation or check on whether gcc signbit works OK to check sign of zero and NaN would be useful. --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com All messages: ------ Rebuild All started: Project: test, Configuration: Debug Win32 ------ Deleting intermediate and output files for project 'test', configuration 'Debug|Win32' Compiling... archive_test.cpp j:\cpp\non_finite_num_facets\test\archive_test.cpp(34) : error C2065: 'archive_test' : undeclared identifier j:\cpp\non_finite_num_facets\test\archive_test.cpp(35) : error C2448: 'BOOST_AUTO_UNIT_TEST' : function-style initializer appears to be a function definition c99_test.cpp c1xx : fatal error C1083: Cannot open source file: '.\c99_test.cpp': No such file or directory extended_test.cpp j:\cpp\non_finite_num_facets\test\extended_test.cpp(31) : error C2065: 'extended_test' : undeclared identifier j:\cpp\non_finite_num_facets\test\extended_test.cpp(32) : error C2448: 'BOOST_AUTO_UNIT_TEST' : function-style initializer appears to be a function definition is_nan_test.cpp j:\cpp\non_finite_num_facets\test\is_nan_test.cpp(35) : error C2065: 'is_nan_test' : undeclared identifier j:\cpp\non_finite_num_facets\test\is_nan_test.cpp(36) : error C2448: 'BOOST_AUTO_UNIT_TEST' : function-style initializer appears to be a function definition lexical_cast_test.cpp j:\cpp\non_finite_num_facets\test\lexical_cast_test.cpp(31) : error C2065: 'lexical_cast_test' : undeclared identifier j:\cpp\non_finite_num_facets\test\lexical_cast_test.cpp(32) : error C2448: 'BOOST_AUTO_UNIT_TEST' : function-style initializer appears to be a function definition numeric_limits_test.cpp j:\cpp\non_finite_num_facets\test\numeric_limits_test.cpp(18) : error C2065: 'numeric_limits_test' : undeclared identifier j:\cpp\non_finite_num_facets\test\numeric_limits_test.cpp(19) : error C2448: 'BOOST_AUTO_UNIT_TEST' : function-style initializer appears to be a function definition sign_bit_test.cpp j:\cpp\non_finite_num_facets\test\sign_bit_test.cpp(23) : error C2065: 'sign_bit_test' : undeclared identifier j:\cpp\non_finite_num_facets\test\sign_bit_test.cpp(24) : error C2448: 'BOOST_AUTO_UNIT_TEST' : function-style initializer appears to be a function definition strict_test.cpp j:\cpp\non_finite_num_facets\test\strict_test.cpp(28) : error C2065: 'strict_test' : undeclared identifier j:\cpp\non_finite_num_facets\test\strict_test.cpp(29) : error C2448: 'BOOST_AUTO_UNIT_TEST' : function-style initializer appears to be a function definition test.cpp | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Johan Råde | Sent: 14 August 2006 16:19 | To: boost@lists.boost.org | Subject: Re: [boost] [serialization] facets for non-finite numbers | | New version uploaded to the vault, with | | 1. More documentation | 2. Documentation in HTML format | 3. Regression tests written with the Boost.Test library | | Where should the code live, if accepted into Boost? | The serialization library is not the right home. | | I would suggest the boost.math library. | This is a already a collection of unrelated sub-libraries, such as | quaternion, special functions and greatest common divisor. | | --Johan Råde | | | | | Johan Råde wrote: | > ----- The Problem ----- | > | > The C++98 standard does not specify how non-finite floating point | > numbers, | > such as infinity and not-a-number, should be represented | in text streams. | > As a result, different platforms use different representations. | > This can cause undefined behavior when text files and | serialization | > archives | > are moved between different platforms. | > | > Some platforms can not even read their own output! | > For instance, the following test fails with VC++ 7.1: | > | > stringstream s; | > double x = numeric_limits<double>::infinity(); | > double y; | > ss << x; | > ss >> y; | > assert(x == y); | > | > | > ----- The Solution ----- | > | > The facets extended_num_put and extended_num_get | > write and read non-finite floating point numbers | > to text streams in a consistent and portable manner. | > | > The following test succeeds with VC++ 7.1: | > | > stringstream s; | > locale old_locale; | > locale tmp_locale(old_locale, new extended_num_put<char>); | > locale new_locale(tmp_locale, new extended_num_get<char>); | > s.imbue(new_locale); | > | > double x = numeric_limits<double>::infinity(); | > double y; | > ss << x; | > ss >> y; | > assert(x == y); | > | | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost |
Paul A Bristow wrote:
Looks good and we NEED it in Boost so that both lexical cast and serialization work right.
signbit and isnan should go in Boost TR1?
I will not do the TR1 isnan and signbit functions. I do no thave time. I'm in the process of starting up a software company. Our product has a shipping date of Nov. 1. My partners tell me that I have already spent too much time on the Boost stuff. I will submit the facets to Boost with my is_nan and sign_bit functions as a private implementation detail. Someone else will have to do the TR1 stuff.
Not sure about the rest.
The facets are not substantial enough to form a new independent library. Of the existing libraries, I think boost.math is the least unsuitable place. If no one has a better idea, I will put the facets in namespace boost::math, and I will put the header files in a folder boost/math/facet. But an attempt to check is compiles with MSVC 8.0 failed - missing
..\c99_test.cpp in zip?
Has been fixed. I c99_test.cpp from the project file. ;-)
And something wrong in archive_test?
Not that I'm aware of. The test succeeds on my machine (VC 7.1). Please elaborate. --Johan Råde
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Johan Råde | Sent: 16 August 2006 08:33 | To: boost@lists.boost.org | Subject: Re: [boost] [serialization] facets for non-finite numbers | | Paul A Bristow wrote: | > Looks good and we NEED it in Boost so that both lexical cast and | > serialization work right. | > | > signbit and isnan should go in Boost TR1? | | I will not do the TR1 isnan and signbit functions. I do no | thave time. I wasn't suggesting that - you have done the tricky bit. | I'm in the process of starting up a software company. | Our product has a shipping date of Nov. 1. | My partners tell me that I have already spent too much time | on the Boost stuff. I'm sure people (who won't realize it) will be very grateful when they manage to read archives that they would have not have been able to. Your reward will be in heaven! | I will submit the facets to Boost with my is_nan and | sign_bit functions | as a private implementation detail. | Someone else will have to do the TR1 stuff. | | > Not sure about the rest. | | The facets are not substantial enough to form a new | independent library. | Of the existing libraries, I think boost.math is the least | unsuitable place. | | If no one has a better idea, I will put the facets in namespace | boost::math, and I will put the header files in a folder | boost/math/facet. OK by me, but I have no knowledge on this. | But an attempt to check is compiles with MSVC 8.0 failed - missing | > ..\c99_test.cpp in zip? | | Has been fixed. I c99_test.cpp from the project file. ;-) | Sorry but I still don't see c99_test.cpp in the non-finite_num_facets.zip uploaded 15 Aug 17>29. | > And something wrong in archive_test? | | Not that I'm aware of. The test succeeds on my machine (VC 7.1). I'll look into it. Thanks Paul
Paul A Bristow wrote:
Sorry but I still don't see c99_test.cpp in the non-finite_num_facets.zip uploaded 15 Aug 17>29.
I have removed the test completely. No test, no problem ;-) (I will put it back in later.) --Johan Råde
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Johan Råde | Sent: 16 August 2006 09:50 | To: boost@lists.boost.org | Subject: Re: [boost] [serialization] facets for non-finite numbers | | Paul A Bristow wrote: | | > Sorry but I still don't see c99_test.cpp in the | non-finite_num_facets.zip | > uploaded 15 Aug 17>29. | | I have removed the test completely. No test, no problem ;-) | (I will put it back in later.) Dirty trick ;-) I managed to get it to compile with MSVC 8.0 (with Boost 1.33.1) but I don't have the serialization library built to it failed to link and run, and I have other more pressing code to do right now. But I am sure it will be OK, and the code will be useful longer-term. 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:
I managed to get it to compile with MSVC 8.0 (with Boost 1.33.1) but I don't have the serialization library built to it failed to link and run, and I have other more pressing code to do right now.
Note that any such test should test the codecvt facet. This should not be related to the serialization library in any way. Robert Ramey
Robert Ramey wrote:
Paul A Bristow wrote:
I managed to get it to compile with MSVC 8.0 (with Boost 1.33.1) but I don't have the serialization library built to it failed to link and run, and I have other more pressing code to do right now.
Note that any such test should test the codecvt facet. This should not be related to the serialization library in any way.
Robert Ramey
Robert, I included some regression tests that test usage with the serialization library. And, lo and behold, the following test fails on VC++ 7.1: stringstream ss; locale old_locale; locale tmp_locale(old_locale, new extended_num_get<char>); locale new_locale(tmp_locale, new extended_num_put<char>); ss.imbue(new_locale); double x = std::numeric_limits<double>::infinity(); { text_oarchive oa(ss); oa & x; } double y; { test_iarchive ia(ss); ia & y; } BOOST_CHECK(x == y); The facets extended_num_put and extended_num_get are never called. Instead std::num_put and std::num_get are called. There is a workaround: first construct the stream, then construct the archive, and then imbue the stream with the new locale. But that seems counter-intuitive. --Johan Råde
Johan Råde wrote:
The facets extended_num_put and extended_num_get are never called. Instead std::num_put and std::num_get are called.
There is a workaround: first construct the stream, then construct the archive, and then imbue the stream with the new locale. But that seems counter-intuitive.
Here is my rendition of your test. Note the addition of the archive open flag archive::no_codecvt to inhibit the serialization library from from using its own code convert facet. #include <sstream> #include "../../../facet/non_finite_num_facets/extended_num_facets.hpp" #include <boost/test/minimal.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> using namespace std; int test_main(int argc, char * argv[]){ stringstream ss; locale old_locale; locale tmp_locale(old_locale, new boost::serialization::extended_num_get<char>); locale new_locale(tmp_locale, new boost::serialization::extended_num_put<char>); ss.imbue(new_locale); double x = std::numeric_limits<double>::infinity(); { boost::archive::text_oarchive oa(ss, boost::archive::no_codecvt); oa & x; } double y; { boost::archive::text_iarchive ia(ss, boost::archive::no_codecvt); ia & y; } BOOST_CHECK(x == y); return 0; } A couple of other observations: this shouldn't be in the serialization namespace - nor should it be in the archive namespace. Its more general - e.g. fixing up lexical_cast and is a "stream" thing not a "serialization" thing. Robert Ramey
--Johan Råde
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Johan Råde wrote:
The facets extended_num_put and extended_num_get are never called. Instead std::num_put and std::num_get are called.
Here is my rendition of your test. Note the addition of the archive open flag archive::no_codecvt to inhibit the serialization library from from using its own code convert facet.
#include <sstream> #include "../../../facet/non_finite_num_facets/extended_num_facets.hpp" #include <boost/test/minimal.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> using namespace std; int test_main(int argc, char * argv[]){ stringstream ss; locale old_locale; locale tmp_locale(old_locale, new boost::serialization::extended_num_get<char>); locale new_locale(tmp_locale, new boost::serialization::extended_num_put<char>); ss.imbue(new_locale); double x = std::numeric_limits<double>::infinity(); { boost::archive::text_oarchive oa(ss, boost::archive::no_codecvt); oa & x; } double y; { boost::archive::text_iarchive ia(ss, boost::archive::no_codecvt); ia & y; } BOOST_CHECK(x == y); return 0; }
Thank you Robert. I will update the documentation of the facets, and the regression tests.
A couple of other observations:
this shouldn't be in the serialization namespace - nor should it be in the archive namespace. Its more general - e.g. fixing up lexical_cast and is a "stream" thing not a "serialization" thing.
I agree. I will move the facets to a different namespace, as soon as I know where to move them. To the boost.math library? Or should there be a new boost.facet library? That would be a good home for the utf8 codecvt facet as well. I will soon ask for an informal review of the facets. That could be a good time to discuss that question. --Johan Råde
Johan Råde <rade <at> maths.lth.se> writes:
Output is consistent with C99. (In particular, negative NaN is written as "-nan".
Paris (U.E.), le 17/08/2006 Bonjour *Negative* Not-A-Number? What is such a beast, and what should it be used for? Next, I vote for an Octonionic Not-A-Number! And I definitely want a notation for the elements of the Stone-Chech compactification of a set which are not in the base set... ;-) Merci Hubert Holin
"Hubert Holin" <Hubert.Holin@lmd.polytechnique.fr> wrote in message news:loom.20060817T140855-29@post.gmane.org...
Johan Råde <rade <at> maths.lth.se> writes:
Output is consistent with C99. (In particular, negative NaN is written as "-nan".
Paris (U.E.), le 17/08/2006
Bonjour
*Negative* Not-A-Number? What is such a beast, and what should it be used for?
It suggests to me a saturation in the negative direction, IOW a number less than -std::numerics<T>::max(). An example use might be when you have an error integrator in a positional servo system, but I don't know if that is the effect here. regards Andy Little
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little | Sent: 17 August 2006 13:51 | To: boost@lists.boost.org | Subject: Re: [boost] [serialization] facets for non-finite numbers | | | "Hubert Holin" <Hubert.Holin@lmd.polytechnique.fr> wrote in message | news:loom.20060817T140855-29@post.gmane.org... | > Johan Råde <rade <at> maths.lth.se> writes: | > | >> Output is consistent with C99. (In particular, | negative NaN is | >> written as "-nan". | > | > Paris (U.E.), le 17/08/2006 | > | > Bonjour | > | > *Negative* Not-A-Number? What is such a beast, and what should | > it be used for? | | It suggests to me a saturation in the negative direction, | IOW a number less than -std::numerics<T>::max(). | | An example use might be when you have an error integrator | in a positional servo | system, but I don't know if that is the effect here. That is indeed the *intention* - but entirely USER-DEFINED and with NO MATH MEANING. NaNs are never > < or == anyway? Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Andy Little | Sent: 17 August 2006 15:45 | To: boost@lists.boost.org | Subject: Re: [boost] [serialization] facets for non-finite numbers | | | Paul Bristow wrote | > That is indeed the *intention* - but entirely USER-DEFINED | and with NO MATH | > MEANING. | > | > NaNs are never > < or == anyway? | | But it tells you where how you got there doesnt it? Maybe - but this is getting OT - the topic was Octonionic Not-A-Numbers ;-) Paul
Paul A Bristow wrote:
| Paul Bristow wrote | > That is indeed the *intention* - but entirely USER-DEFINED | and with NO MATH | > MEANING. | > | > NaNs are never > < or == anyway? | | But it tells you where how you got there doesnt it?
Maybe - but this is getting OT - the topic was Octonionic Not-A-Numbers ;-)
Is this really off-topic? I've seen everyone assert that -nan has no mathematical meaning. Does this mean that there is no pfficial specification (whether it is "mathematically meaningful" or not) of how a -nan can arise as a result of an arithmetic operation?
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Deane Yang | Sent: 17 August 2006 17:12 | To: boost@lists.boost.org | Subject: Re: [boost] The meaning of -nan (was | [serialization] facets for non-finite numbers) | | Paul A Bristow wrote: | > | Paul Bristow wrote | > | > That is indeed the *intention* - but entirely USER-DEFINED | > | and with NO MATH | > | > MEANING. | > | > | > | > NaNs are never > < or == anyway? | > | | > | But it tells you where how you got there doesnt it? | > | > Maybe - but this is getting OT - the topic was Octonionic | Not-A-Numbers ;-) | > | | Is this really off-topic? I've seen everyone assert that -nan has no | mathematical meaning. Does this mean that there is no pfficial | specification (whether it is "mathematically meaningful" or | not) of how a -nan can arise as a result of an arithmetic operation? Well the 'official' position seems entirely unclear to me with IEEE754, IEEE754R - still unreleased, and a high degree of non-compliance/disagreement among manufacturers and vendors. But a NaN is a NaN, whatever the sign, only the exponent field determines NaN-ness AFAIK. Apart from sign there are also lots of significand bits whose meaning is officially undefined. I suspect that -NaN can only arise from the use of copysign on an existing NaN. But I am confident that this whole business is 'User-Defined'. But the ability to stream out a signed NaN and stream back in a signed NaN is potentially VERY useful. 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:
But a NaN is a NaN, whatever the sign, only the exponent field determines NaN-ness AFAIK.
Apart from sign there are also lots of significand bits whose meaning is officially undefined.
The exponent field is all 1's, just like infinity, but the mantissa field has at least one 1 bit. All 0's in the mantissa would be infinity. -- Dick Hadsell 914-259-6320 Fax: 914-259-6499 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 44 South Broadway, White Plains, NY 10601
Richard Hadsell wrote:
Paul A Bristow wrote:
But a NaN is a NaN, whatever the sign, only the exponent field determines NaN-ness AFAIK.
Apart from sign there are also lots of significand bits whose meaning is officially undefined.
The exponent field is all 1's, just like infinity, but the mantissa field has at least one 1 bit. All 0's in the mantissa would be infinity.
For more information about negative nan, and related beasts, read the the section on the IEEE 754 standard in documentation of my library. If you still want to know more, follow the links listed there. The library is in the vault: serialization/non_finite_num_facets.zip Hubert Holin wrote:
*Negative* Not-A-Number? What is such a beast, and what should it be used for? Next, I vote for an Octonionic Not-A-Number!
I have good news for you Hubert ;-) There already are octonionic not-a-number's. The following program gives the output "false" when I run it on VC++ 7.1. (On some compilers you may have to turn off the optimizations.) #include <boost/math/octonion.hpp> int main() { boost::math::octonion<double> oct(std::numeric_limits<double>::quiet_NaN()); std::cout << std::boolalpha << (oct == oct) << std::endl; } --Johan Råde
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Hubert Holin | Sent: 17 August 2006 13:15 | To: boost@lists.boost.org | Subject: Re: [boost] [serialization] facets for non-finite numbers | | Johan Råde <rade <at> maths.lth.se> writes: | | > Output is consistent with C99. (In particular, | negative NaN is | > written as "-nan". | | Paris (U.E.), le 17/08/2006 | | Bonjour | | *Negative* Not-A-Number? What is such a beast, and what should | it be used for? Next, I vote for an Octonionic Not-A-Number! And | I definitely want a notation for the elements of the Stone-Chech | compactification of a set which are not in the base set... ;-) Chill, man chill - your imagination is wonderfully out of control! You've obviously missed all the previous equally over-heated arguments ;-) This makes NO pretence at *any mathematical meaning at all*, but the *signbit* remains a potentially valuable bit that can be used for User Defined Purposes, (as can all other NaN bits that have no math meaning either) most obviously to indicate membership of the set of missing values ;-) Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com
Hubert Holin wrote:
*Negative* Not-A-Number? What is such a beast,
According to the IEEE 754 standard there is such a beast. According the C99 standard, negative NaN (not-a-number) should be represented as "-nan" in text streams. Negative NaN is simply a naN with a binary representation where the sign bit is 1. There is no mathematical interpretation. The expression -std::numeric_limits<T>::quiet_nan() gives you a negative NaN.
and what should it be used for?
No idea. --Johan Råde
participants (7)
-
Andy Little -
Deane Yang -
Hubert Holin -
Johan Råde -
Paul A Bristow -
Richard Hadsell -
Robert Ramey