Re: [boost] [multiprecision] Radix-2 typedef naming convention

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: 
http://en.wikipedia.org/wiki/IEEE_floating_point#Basic_formats

But I see that brings up a new set of names: binary32_float, binary64_float, 
binary128_float or variations thereof.

John.