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

Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
From: Christopher Kormanyos (e_float_at_[hidden])
Date: 2013-11-01 17:27:52

>> 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.
> John.

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?

John, do you have any kind of strong tendency?
My personal favorites are:

1) float32_t, float64_t, etc...
2) float_single_t, float_double_t, float_quad_t, etc...
3) float24_t, float53_t, etc...

Sincerely, Chris.

On Friday, November 1, 2013 5:54 PM, John Maddock <john_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.

John.

PS we could also use float_single_t, float_double_t, float_quad_t etc.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost