Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
From: John Maddock (john_at_[hidden])
Date: 2013-11-02 08:23:25
>> I would still stick with float32_t, float64_t, etc. But I could easily
>> be swayed to another naming convention. Can anyone come up with any with
>> convincing reason why a certain naming convention should be selected, or
>> why not?
> The numbers in such typedefs are, conventionally, sizes, or at least
> thought to be so. Interpreting them as significand bits for floating point
> types is surprising. Sizes are only useful for floating point when the
> representation is well defined.
>> John, do you have any kind of strong tendency?
>> My personal favorites are:
>> 1) float32_t, float64_t, etc...
> +1 for types with well-defined representation.
>> 2) float_single_t, float_double_t, float_quad_t, etc...
>> 3) float24_t, float53_t, etc...
> Neither of those is particularly helpful for the purpose. For 2, is the
> number of significand bits prescribed universally for each?
Yes they're IEEE standards:
But I see that brings up a new set of names: binary32_float, binary64_float,
binary128_float or variations thereof.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk