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

Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2013-11-01 09:04:31

> -----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]