From: Paul A Bristow (pbristow_at_[hidden])
Date: 2006-03-17 13:06:20
| -----Original Message-----
| From: boost-bounces_at_[hidden]
| [mailto:boost-bounces_at_[hidden]] On Behalf Of Caleb Epstein
| Sent: 17 March 2006 15:13
| To: boost_at_[hidden]
| Subject: Re: [boost] [serialization]
| Serialisation/deserialisationoffloating-point values
| On 3/17/06, Paul A Bristow <pbristow_at_[hidden]> wrote:
| > Ooops - this is a typo.
| > It should of course be 3010/10000.
| Which is one of the reasons magic numbers in code are best avoided.
Touche! Case proven!
| It sure would be nice if one could just use
| numeric_limits<T>::digits10 + 2 instead
| of numeric_limits<T>::digits * 3010 / 10000, but the former gives a
| different result for float (8 instead of 9).
| Perhaps this cryptic calculation might be best addressed by a
| boost::numeric_limits<T> which could extend std::numeric_limits<T> and
| include Paul Bristow's proposed max_digits10 (see
Well this would be faster than the glacial speed of simple no-brain changes
like this to Standards.
And while we are at it, the macros I proposed to WG14 for C could also be
added, in case these are more convenient for (C++ AND C) users.
Date: 2005-11-30, version 1
#define FLT_MAXDIG10 (2+(FLT_MANT_DIG * 3010)/10000)
#define DBL_MAXDIG10 (2+ (DBL_MANT_DIG * 3010)/10000)
#define LDBL_MAXDIG10 (2+ (LDBL_MANT_DIG * 3010)/10000)
which yield the following values on typical implementations:
FLT_DIG 6, FLT_MAXDIG10 9
DBL_DIG 15, DBL_MAXDIG10 17
LDBL_DIG 19, LDBL_MAXDIG10 21
Should it go into boost/detail/limits.hpp?
I don't feel qualfied to do this, but it is long overdue to sort out this
(and get on with the much more important problem of failure of
round-tripping of all uses of stringstream, crucially lexical_cast and
-- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow_at_[hidden] http://www.hetp.u-net.com/index.html http://www.hetp.u-net.com/Paul%20A%20Bristow%20info.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk