Boost logo

Boost :

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 +44 1539 561830  07714330204 pbristow_at_[hidden] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk