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 12:23:53

>>>> In John's new radix-2 MP back end, names are used for common types
>>>> such as:
>>>>
>>>> float24_t, float53_t, float113_t.
>>>>
>>>> In our proposal for floating-point typedef's having specified widths,
>>>> we use names such as:
>>>>
>>>> float32_t, float64_t, float128_t.
>>>> Both conventions make sense in sensible ways.
>>>> But only one naming convention should be used, and it should be used
>>>> consistently.
>>>>
>>>> Which one will it be?
> 
>> Good point.
> 
>>> I think float32_t, float64_t, float128_t are better since they
>>> describe the size of the type and are aligned with integer typedefs.
> 
>> That was my thought, although note that in the case of the
>> Boost.Multiprecision types these are emulations of those hardware
>> types and are not actually 32, 64 or 128 bits in size.  And evn in
>> hardware, an 80-bit extended real may actually occupy 128
>> bits in memory...

Ahhh... I see your point, John. The multiprecision types are not
intended to be IEEE754 conformant. And our own proposal
for typedefs having specified widths reserves such names
for IEEE754 conformant types.

I keep going back and forth on this one in my mind.
I guess I ended up confusing myself here. 

> I prefer float32_t, float64_t, float128_t
> They look like ducks and quack like ducks, so let's allow
> people to assume they are ducks?

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.

Sincerely, Chris.





On Friday, November 1, 2013 2:04 PM, Paul A. Bristow <pbristow_at_[hidden]> wrote:
 


> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of John Maddock
> Sent: Friday, November 01, 2013 12:15 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
> 
> >> In John's new radix-2 MP back end, names are used for common types
> >> such as:
> >>
> >> float24_t, float53_t, float113_t.
> >>
> >> In our proposal for floating-point typedef's having specified widths,
> >> we use names such as:
> >>
> >> float32_t, float64_t, float128_t.
> >> Both conventions make sense in sensible ways.
> >> But only one naming convention should be used, and it should be used
> >> consistently.
> >>
> >> Which one will it be?
> 
> Good point.
> 
> > I think float32_t, float64_t, float128_t are better since they
> > describe the size of the type and are aligned with integer typedefs.
> 
> That was my thought, although note that in the case of the Boost.Multiprecision types these are
> emulations of those hardware types and are not actually 32, 64 or 128 bits in size.  And evn in
hardware,
> an 80-bit extended real may actually occupy 128 bits in memory...

I prefer float32_t, float64_t, float128_t

They look like ducks and quack like ducks, so let's allow people to assume they are ducks?

(Of course, they will discover that they are not really ducks when they see the absurdly large
ranges of exponents!)

I have yet to imagine a use for a type that does not use the 24, 53, and 113 significand bits
*named*  float32_t, float64_t, float128_t, but another name like float42_t is always available?

Paul

---
Paul A. Bristow,
Prizet Farmhouse, Kendal LA8 8AB  UK
[phone]  07714330204
pbristow_at_[hidden]






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