Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2013-11-05 12:35:36
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
> Sent: Tuesday, November 05, 2013 4:53 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
> >Thank you for this astute observation. In fact, we already have a
> >proposal for optional typedefs such as float32_t, float64_t, and
> >float128_t. They are to be defined in the global and std namespaces,
> >and they are to be placed in new headers <stdfloat.h> and <cstdfloat>,
> >Why not name the new radix-2 multiprecision types as follows?
> >* boost::multiprecision::cpp_bin_float_24
> >* boost::multiprecision::cpp_bin_float_53
> >* boost::multiprecision::cpp_bin_float_113
> >* and the one for octuple precision
> Sorry but that doesn't really work either - up until now we have consistently used:
> to mean "Floating point type with at least N decimal digits", this is used consistently not only
> cpp_dec_float, but in binary floating point types such as mpfr_float and mpf_float where we have
> typedefs such as:
> typedef something mpfr_float_50;
> typedef something mpfr_float_100;
> Which each have enough binary digits to guarantee 50 and 100 decimal place precision respectively.
> So cpp_bin_float follows this and also has:
> typedef something cpp_bin_float_50;
> typedef something cpp_bin_float_100;
> So bit counts have to use a different naming convention to avoid confusion.
> How about:
I'm not sure what these actually provide.
Is cpp_bin_float_double the same as the current boost::multiprecision::float53_t
and *emulates* std::float64_t which is true IEEE layout 64-bit double?
whereas float_53_t has 53 significand but a much bigger exponent)?
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk