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

Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-11-02 08:12:34

On Nov 1, 2013, at 5:27 PM, Christopher Kormanyos <e_float_at_[hidden]> wrote:

>>> I might still prefer this way. But we would need to
>>> document that these types are not intended to be
>>> equivalent to binary32, binary64, etc. in IEEE754.
> 
>> Nod, they're functionally equivalent, not bit-for-bit equivalent.
> 
> Adding a sentence or two in the docs should be sufficient.
> 
>> PS we could also use float_single_t, float_double_t, float_quad_t etc.
> 
> Those are also good names. But somehow I feel that adding
> yet another set of names might just be going in the wrong direction.
> 
> 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? For 3, the size confusion is the problem.

What about float24b_t, float53b_t, etc.? The "b" makes those stand apart from the usual convention.

Should there be leeway in the number of bits, giving way to something like float_least24b_t, the smallest available type with at least 24 significand bits?

___
Rob

(Sent from my portable computation engine)