[floating point utilities] new version
Hi, I have uploaded version 3 of the floating point utilities library to the vault. The library is in the folder Math - Numerics. The library provides portable and optimized implementations of isnan, fpclassify, signbit etc. It also provides facets for portable handling of infinity and NaN in text streams. If you want text files with floating point numbers to be portable, and if the files may contain infinity or NaN, then you should use this library. This also applies to text serialization archives. Compared with version 2, there are only minor changes: 1. I have removed all use of partial template specialization and I have added BOOST_TYPENAME and BOOST_STATIC_CONSTANT macros. Now the library should work with older compilers, such as MSVC 6.5. 2. I now use the header boost/detail/endian.hpp. (I didn't before, because I didn't trust that header. But I now think it is better to use endian.hpp, and to fix any problems with the header as they show up.) 3. General code clean-up and simplification. 4. More discussion of portability issues in the docs. There are no changes to the interface. If anyone has time to test the library, I would be interested in the results. Thank you, Johan Råde
This library is really intersting to have portable floating point numbers in text files but it would be really portable if you dealt with the representation of the exponent in scientific notation because this is not clearly stated in the standard (i.e. the number of digits of the exponent is greater or equal to 2 but some compiler write 2 and some others 3 which makes non portable outputs). example: 1.0e+003 or 1.0e+03. Thank you for the update. Regards, F. Bron boost-bounces@lists.boost.org a écrit sur 07/01/2008 18:32:30 :
Hi,
I have uploaded version 3 of the floating point utilities library tothe vault. The library is in the folder Math - Numerics.
The library provides portable and optimized implementations of isnan, fpclassify, signbit etc. It also provides facets for portable handling of infinity and NaN in text streams.
If you want text files with floating point numbers to be portable, and if the files may contain infinity or NaN, then you should use this library. This also applies to text serialization archives.
Compared with version 2, there are only minor changes:
1. I have removed all use of partial template specialization and I have added BOOST_TYPENAME and BOOST_STATIC_CONSTANT macros. Now the library should work with older compilers, such as MSVC 6.5.
2. I now use the header boost/detail/endian.hpp. (I didn't before, because I didn't trust that header. But I now think it is better to use endian.hpp, and to fix any problems with the header as they show up.)
3. General code clean-up and simplification.
4. More discussion of portability issues in the docs.
There are no changes to the interface.
If anyone has time to test the library, I would be interested in the results.
Thank you, Johan Råde
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.
frederic.bron@alcan.com wrote:
it would be really portable if you dealt with the representation of the exponent in scientific notation because this is not clearly stated in the standard (i.e. the number of digits of the exponent is greater or equal to 2 but some compiler write 2 and some others 3 which makes non portable outputs). example: 1.0e+003 or 1.0e+03.
Portability of formatting and parsing means that output that has been formatted by one implementation of the standard library can be parsed by other implementations of the standard library. Hence, as long as all implementations of the standard library can parse both 1.0e+003 or 1.0e+03 there is no portability issue here. The representation of infinity and NaN is a more serious matter. Some implementations of the standard library do format them in a way that other implementations can not parse. This can for instance cause deserialization of text archives to crash. --Johan
Ok, this explains why your library is so usefull (thank you). My concern is that I have lots of tests that I would like to run on different machines/systems and the easiest way to check the results is to compare output text files with reference text files. This is not possible because Windows writes 1.0e+003 and linux 1.0e+03! I think this is something missing in the standard that would really help. Fred boost-bounces@lists.boost.org a écrit sur 07/01/2008 19:26:30 :
frederic.bron@alcan.com wrote:
it would be really portable if you dealt with the representation
of the exponent in scientific notation
because this is not clearly stated in the standard (i.e. the number of digits of the exponent is greater or equal to 2 but some compiler write 2 and some others 3 which makes non portable outputs). example: 1.0e+003 or 1.0e+03.
Portability of formatting and parsing means that output that has been formatted by one implementation of the standard library can be parsed by other implementations of the standard library. Hence, as long as all implementations of the standard library can parse both 1.0e+003 or 1.0e+03 there is no portability issue here.
The representation of infinity and NaN is a more serious matter. Some implementations of the standard library do format them in a way that other implementations can not parse. This can for instance cause deserialization of text archives to crash.
Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.
frederic.bron@alcan.com wrote:
Ok, this explains why your library is so usefull (thank you). My concern is that I have lots of tests that I would like to run on different machines/systems and the easiest way to check the results is to compare output text files with reference text files. This is not possible because Windows writes 1.0e+003 and linux 1.0e+03! I think this is something missing in the standard that would really help.
If having exactly the same formatting of floating point numbers on different platforms is important to you, then you can fix that by deriving your own facet class from std::num_put. If it is only for testing purposes, then you can probably do without many of the bells in whistles in the standard implementation. It should not be too much work. Good luck. --Johan
Johan Råde wrote:
2. I now use the header boost/detail/endian.hpp. (I didn't before, because I didn't trust that header. But I now think it is better to use endian.hpp, and to fix any problems with the header as they show up.)
I should add that by using endian.hpp, I have been able to make the code faster in some cases. --Johan
participants (2)
-
frederic.bron＠alcan.com -
Johan Råde