[format] - exponential format, NaN and infinity
This is about output of real values (float, double, ...) in exponential format and output of not a number and infinity. My concern is that in C++, the output differs from one compiler/machine to another. It would be very nice if boost::format could garantee the same output on every computer. For example, the following code gives the following output on various machines (using boost 1.33.1): std::cout << format("%1% ") % 1e12 ; std::cout << format("%1% ") % std::numeric_limits<double>::quiet_NaN() ; std::cout << format("%1% ") % std::numeric_limits<double>::infinity() ; std::cout << format("%1%") % (-std::numeric_limits<double>::infinity()) ; The output on cygwin (compiled with g++ 3.4.4) is: 1e+12 nan inf -inf The output on windows (compiled with g++ 3.4.4 on cygwin with flag -mno-cygwin) is: 1e+012 1.#QNAN 1.#INF -1.#INF The output on Tru64 (compiled with g++ 3.4.4) is: 1e+12 NaNQ INF -INF This makes difficult to check if the programs do the same on various machines as soon as tests include output of numbers. Here, I cite section 7.19.6.1 The fprintf function of standard "Programming languages — C" ISO/IEC 9899:1999(E): The effect of the printf function in C is descibed as: A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity — which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) — which style, and the meaning of any n-char-sequence, is implementation-defined. A double argument representing a floating-point number is converted in the style [-]d.ddd e±dd, ... The exponent always contains at least two digits, and only as many more digits as necessary to represent the exponent. Could we have the same in C++: 1. 2 digit in the exponent and more only if needed 2. a standard format for not a number and infinity: nan and inf. (They are roughtly implementation defined in C!) In the C++ standard "Programming languages — C++" ISO/IEC 14882:2003(E), the only reference to printf is in 27.8.2 C Library files where we can find the list of functions in cstdio. Also using cout, there is no description of how to handle NaN, infinity and the number of digits in the exponents. The function should be described in the previous C standard "Programming languages – C" ISO/IEC 9899:1990 which I do not have. Thanks, F. Bron 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:
This is about output of real values (float, double, ...) in exponential format and output of not a number and infinity. My concern is that in C++, the output differs from one compiler/machine to another. It would be very nice if boost::format could garantee the same output on every computer.
I'm not 100% sure this will solve your problem, but you should have a look at the floating_point_utils from Johan Rade with help from John Maddock and others. You can find it in the vault here http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Math%20-%20Numerics It's not an official lib yet, but I believe it's been testing on a whole bunch of compilers and platforms. There's a long discussion of this in the mail archive -- look for 'fpclassify' on this page: http://lists.boost.org/Archives/boost/2006/12/index.php HTH, Jeff
I also raised this issue with the Standards group http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2022.pdf but I suspect getting C++0x out of the door is a higher priority. So maybe it is a problem that Boost should fully solve - much of the work has already been done by Johan Rade. Possibly a GSoC project to polish it up/off? 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 Jeff Garland Sent: 14 March 2007 23:15 To: boost@lists.boost.org Subject: Re: [boost] [format] - exponential format, NaN and infinity
frederic.bron@alcan.com wrote:
This is about output of real values (float, double, ...) in exponential format and output of not a number and infinity. My concern is that in C++, the output differs from one compiler/machine to another. It would be very nice if boost::format could garantee the same output on every computer.
I'm not 100% sure this will solve your problem, but you should have a look at the floating_point_utils from Johan Rade with help from John Maddock and others. You can find it in the vault here
http://boost-consulting.com/vault/index.php?&direction=0&order= &directory=Math%20-%20Numerics
It's not an official lib yet, but I believe it's been testing on a whole bunch of compilers and platforms. There's a long discussion of this in the mail archive -- look for 'fpclassify' on this page:
http://lists.boost.org/Archives/boost/2006/12/index.php
HTH,
Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I have tried the floating_point_utilities_v2 which is very good for inf and nan. Thanks! Why isn't it part of boost? However, there is still the problem with the number of digits in the exponent: 2 with unix/cygwin (1e12) and 3 with windows (1e012). Regards, F. Bron ___________________________________ Frédéric Bron (frederic.bron@alcan.com) Unité ALT, Alcan CRV, BP 27, 38341 Voreppe téléphone : +33 4 76 57 81 72 télécopie : +33 4 76 57 80 99 Jeff Garland <jeff@crystalclearso Pour : boost@lists.boost.org ftware.com> cc : (ccc : Frederic Bron/Alcan) Envoyé par : Objet : Re: [boost] [format] - exponential format, NaN and infinity boost-bounces@lists. boost.org 15/03/2007 00:14 Veuillez répondre à boost frederic.bron@alcan.com wrote:
This is about output of real values (float, double, ...) in exponential format and output of not a number and infinity. My concern is that in C++, the output differs from one compiler/machine to another. It would be very nice if boost::format could garantee the same output on every computer.
I'm not 100% sure this will solve your problem, but you should have a look at the floating_point_utils from Johan Rade with help from John Maddock and others. You can find it in the vault here http://boost-consulting.com/vault/index.php?&direction=0&order=&directory=Math%20-%20Numerics It's not an official lib yet, but I believe it's been testing on a whole bunch of compilers and platforms. There's a long discussion of this in the mail archive -- look for 'fpclassify' on this page: http://lists.boost.org/Archives/boost/2006/12/index.php HTH, Jeff _______________________________________________ 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:
I have tried the floating_point_utilities_v2 which is very good for inf and nan. Thanks! Why isn't it part of boost?
It's in the review queue http://www.boost.org/more/formal_review_schedule.html After it is accepted it can officially become part of Boost.
However, there is still the problem with the number of digits in the exponent: 2 with unix/cygwin (1e12) and 3 with windows (1e012).
I suspect this is also a deficiency in the facet. According the Langer and Kreft (appendix b) the output will have 'at least 2 digits'...which is exactly the problem you are having :-( Jeff
frederic.bron@alcan.com wrote:
However, there is still the problem with the number of digits in the exponent: 2 with unix/cygwin (1e12) and 3 with windows (1e012).
In theory, you could solve the problem by putting together your own implementation of std::num_put and std::num_get. In practice, the best solution might be to replace strings such as 1e012 by 1e12 before you use them. This is very easy using the boost regex library. --Johan Råde
frederic.bron@alcan.com wrote:
Could we have the same in C++: 1. 2 digit in the exponent and more only if needed
The floating_point_utilities library does not address this issue.
2. a standard format for not a number and infinity: nan and inf. (They are roughtly implementation defined in C!)
The floating_point_utilities library solves this problem. See the documentation of the header nonfinite_num_facets.hpp. The library also provides portable implementations of fpclassify, isnan, signbit etc. The library is available in the vault: http://boost-consulting.com/vault/index.php?directory=Math%20-%20Numerics& --Johan Råde
Johan Råde wrote:
The floating_point_utilities library solves this problem. See the documentation of the header nonfinite_num_facets.hpp.
The library also provides portable implementations of fpclassify, isnan, signbit etc.
Hi Johan, What do you think about using the platform signbit and copysign if available (in TR1, C99, MSVC, ...)? There is a chance that the compiler optimizes the builtins better than expressions only using arithmetic primitives. I realize that testing the availability of copysign or copysign_ is probably difficult to do in the headers only, but for a subset of platforms it should be feasible. Regards, Stephan
Stephan Tolksdorf wrote:
Johan Råde wrote:
The floating_point_utilities library solves this problem. See the documentation of the header nonfinite_num_facets.hpp.
The library also provides portable implementations of fpclassify, isnan, signbit etc.
Hi Johan,
What do you think about using the platform signbit and copysign if available (in TR1, C99, MSVC, ...)? There is a chance that the compiler optimizes the builtins better than expressions only using arithmetic primitives.
My implementation does not use any floating point operations. It only does logical bit operations on the binary representations of floating the numbers. I did some timing tests on VC++ 7.1. There my code was faster than the native implementation, in some cases much faster. However, the native implementation might of course be faster on some platforms.
I realize that testing the availability of copysign or copysign_ is probably difficult to do in the headers only, but for a subset of platforms it should be feasible.
One solution might be to let the user decide which implementation to use. My implementation would be the default, but if the user defines the macro BOOST_USE_NATIVE_FPCLASSIFY, then my code would call the native implementation instead. --Johan
One solution might be to let the user decide which implementation to use. My implementation would be the default, but if the user defines the macro BOOST_USE_NATIVE_FPCLASSIFY, then my code would call the native implementation instead.
That would probably be a good option to have. For platforms known to have an efficient copysign/signbit it could also default to the native version, though that would need some testing. Stephan
Stephan Tolksdorf wrote:
One solution might be to let the user decide which implementation to use. My implementation would be the default, but if the user defines the macro BOOST_USE_NATIVE_FPCLASSIFY, then my code would call the native implementation instead.
That would probably be a good option to have. For platforms known to have an efficient copysign/signbit it could also default to the native version, though that would need some testing.
I agree. --Johan
participants (5)
-
frederic.bron＠alcan.com -
Jeff Garland -
Johan Råde -
Paul A Bristow -
Stephan Tolksdorf