[multiprecision] Radix-2 typedef naming convention
Hi folks, Lost the original message here. Sorry. 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? Sincerely, Chris.
On Friday 01 November 2013 11:35:34 Christopher Kormanyos wrote:
Hi folks,
Lost the original message here. Sorry.
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?
I think float32_t, float64_t, float128_t are better since they describe the size of the type and are aligned with integer typedefs.
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... John.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Friday, November 01, 2013 12:15 PM To: boost@lists.boost.org 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@hetp.u-net.com
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
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Friday, November 01, 2013 12:15 PM To: boost@lists.boost.org 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@hetp.u-net.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
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.
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
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
On Nov 1, 2013, at 5:27 PM, Christopher Kormanyos
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)
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?
Yes they're IEEE standards: http://en.wikipedia.org/wiki/IEEE_floating_point#Basic_formats But I see that brings up a new set of names: binary32_float, binary64_float, binary128_float or variations thereof. John.
On 2/11/2013 05:23, Quoth Christopher Kormanyos:
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'm just a bystander (who probably won't be using the library, so take this with a grain of salt), but I'm leaning towards thinking it better to reserve those names (float32_t etc) for actually IEEE754 compliant types, eg. some future <cstdint> or similar defining "typedef float float32_t" etc. (It wouldn't surprise me if some existing applications already do something similar.) Given that Boost has stdint emulation this would also reserve boost::float32_t etc. You might be able to use boost::multiprecision::float32_t etc but I think this might be too confusing, especially for the people who are in the habit of "using namespace". So something unique might be better. I don't know whether that should be "mp_float32_t" or "float_single_t" or "float24p_t" or some other combination.
I'm just a bystander (who probably won't be using the library, so take this with a grain of salt), but I'm leaning towards thinking it better to reserve those names (float32_t etc) for actually IEEE754 compliant types, eg. some future <cstdint> or similar defining "typedef float float32_t" etc. (It wouldn't surprise me if some existing applications already do something similar.)
Thank you for this astute observation. In fact, we already
have a proposal for optional typedefs such as float32_t,
float64_t, and float128_t. They are to be defined in the global
and std namespaces, and they are to be placed in new headers
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'm just a bystander (who probably won't be using the library, so take this with a grain of salt), but I'm leaning towards thinking it better to reserve those names (float32_t etc) for actually IEEE754 compliant types, eg. some future <cstdint> or similar defining "typedef float float32_t" etc. (It wouldn't surprise me if some existing applications already do something similar.) Given that Boost has stdint emulation this would also reserve boost::float32_t etc. You might be able to use boost::multiprecision::float32_t etc but I think this might be too confusing, especially for the people who are in the habit of "using namespace". So something unique might be better. I don't know whether that should be "mp_float32_t" or "float_single_t" or "float24p_t" or some other combination. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thank you for this astute observation. In fact, we already have a proposal for optional typedefs such as float32_t, float64_t, and float128_t. They are to be defined in the global and std namespaces, and they are to be placed in new headers
and <cstdfloat>, respectively.
Why not name the new radix-2 multiprecision types as follows? * boost::multiprecision::cpp_bin_float_24 * boost::multiprecision::cpp_bin_float_53 * boost::multiprecision::cpp_bin_float_113 * and the one for octuple precision
Sorry but that doesn't really work either - up until now we have consistently used: float_type_N to mean "Floating point type with at least N decimal digits", this is used consistently not only in cpp_dec_float, but in binary floating point types such as mpfr_float and mpf_float where we have typedefs such as: typedef something mpfr_float_50; typedef something mpfr_float_100; Which each have enough binary digits to guarantee 50 and 100 decimal place precision respectively. So cpp_bin_float follows this and also has: typedef something cpp_bin_float_50; typedef something cpp_bin_float_100; So bit counts have to use a different naming convention to avoid confusion. How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad; ? John.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Tuesday, November 05, 2013 4:53 PM To: boost@lists.boost.org Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
Thank you for this astute observation. In fact, we already have a proposal for optional typedefs such as float32_t, float64_t, and float128_t. They are to be defined in the global and std namespaces, and they are to be placed in new headers
and <cstdfloat>, respectively. Why not name the new radix-2 multiprecision types as follows? * boost::multiprecision::cpp_bin_float_24 * boost::multiprecision::cpp_bin_float_53 * boost::multiprecision::cpp_bin_float_113 * and the one for octuple precision
Sorry but that doesn't really work either - up until now we have consistently used:
float_type_N
to mean "Floating point type with at least N decimal digits", this is used consistently not only in cpp_dec_float, but in binary floating point types such as mpfr_float and mpf_float where we have typedefs such as:
typedef something mpfr_float_50; typedef something mpfr_float_100;
Which each have enough binary digits to guarantee 50 and 100 decimal place precision respectively.
So cpp_bin_float follows this and also has:
typedef something cpp_bin_float_50; typedef something cpp_bin_float_100;
So bit counts have to use a different naming convention to avoid confusion.
How about:
cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
I'm not sure what these actually provide. Is cpp_bin_float_double the same as the current boost::multiprecision::float53_t and *emulates* std::float64_t which is true IEEE layout 64-bit double? whereas float_53_t has 53 significand but a much bigger exponent)? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
So bit counts have to use a different naming convention to avoid confusion.
How about:
cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
I'm not sure what these actually provide.
We're trying to find "good" names for the software emulations of the IEEE single/double and quad precision (32, 64 and 128 bit) types.
Is cpp_bin_float_double the same as the current boost::multiprecision::float53_t
We don't have anything currently.
and *emulates* std::float64_t which is true IEEE layout 64-bit double?
Yes.
whereas float_53_t has 53 significand but a much bigger exponent)?
No the same exponent range, and the same behavior in all aspects except size and bit-layout. John.
Why not name the new radix-2 multiprecision types as follows? * boost::multiprecision::cpp_bin_float_24 * boost::multiprecision::cpp_bin_float_53 * boost::multiprecision::cpp_bin_float_113 * and the one for octuple precision
Sorry but that doesn't really work either - up until now we have consistently used:
float_type_N
to mean "Floating point type with at least N decimal digits", this is used consistently not only in cpp_dec_float, but in binary floating point types such as mpfr_float and mpf_float where we have typedefs such as:
Oh yeah. You're right again, and I flubbed up again. Thanks.
How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
Fine with me! Those are good names --- consistent with
existing Boost style, easy to recognize, and unambiguous.
Can we get a consensus on those names?
Paul?
Others?
Thanks for your patience.
Sincerely, Chris.
On Tuesday, November 5, 2013 5:53 PM, John Maddock
Thank you for this astute observation. In fact, we already have a proposal for optional typedefs such as float32_t, float64_t, and float128_t. They are to be defined in the global and std namespaces, and they are to be placed in new headers
and <cstdfloat>, respectively.
Why not name the new radix-2 multiprecision types as follows? * boost::multiprecision::cpp_bin_float_24 * boost::multiprecision::cpp_bin_float_53 * boost::multiprecision::cpp_bin_float_113 * and the one for octuple precision
Sorry but that doesn't really work either - up until now we have consistently used: float_type_N to mean "Floating point type with at least N decimal digits", this is used consistently not only in cpp_dec_float, but in binary floating point types such as mpfr_float and mpf_float where we have typedefs such as: typedef something mpfr_float_50; typedef something mpfr_float_100; Which each have enough binary digits to guarantee 50 and 100 decimal place precision respectively. So cpp_bin_float follows this and also has: typedef something cpp_bin_float_50; typedef something cpp_bin_float_100; So bit counts have to use a different naming convention to avoid confusion. How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad; ? John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Oh yeah. You're right again, and I flubbed up again. Thanks.
How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
Fine with me! Those are good names --- consistent with existing Boost style, easy to recognize, and unambiguous. Can we get a consensus on those names?
One other suggestion: cpp_float32_t cpp_float64_t cpp_float128_t which keeps the "cuteness" and link to the names of the hardware types, but the cpp_ prefix indicates it's a software emulation? John.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Wednesday, November 06, 2013 9:08 AM To: boost@lists.boost.org Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
Fine with me! Those are good names --- consistent with existing Boost style, easy to recognize, and unambiguous. Can we get a consensus on those names?
One other suggestion:
cpp_float32_t cpp_float64_t cpp_float128_t
which keeps the "cuteness" and link to the names of the hardware types, but the cpp_ prefix indicates it's a software emulation?
I think I like these a bit better - except that should they be cpp_bin_float32_t cpp_bin_float64_t cpp_bin_float128_t I know it's more to type, but it's important that they are recognised as a binary type? Is double always 64 bit and float always 32? And quad isn't a float-point type yet? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On Wed, Nov 6, 2013 at 1:53 PM, Paul A. Bristow
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Wednesday, November 06, 2013 9:08 AM To: boost@lists.boost.org Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
Fine with me! Those are good names --- consistent with existing Boost style, easy to recognize, and unambiguous. Can we get a consensus on those names?
One other suggestion:
cpp_float32_t cpp_float64_t cpp_float128_t
which keeps the "cuteness" and link to the names of the hardware types, but the cpp_ prefix indicates it's a software emulation?
I think I like these a bit better - except that should they be
cpp_bin_float32_t cpp_bin_float64_t cpp_bin_float128_t
I know it's more to type, but it's important that they are recognised as a binary type?
I'm not a user of Boost.Multiprecision, but maybe namespaces would do a better job in distinguishing the types? Injecting various tags into the type names feels like C-style. Or maybe a trait to construct the necessary type: template< unsigned int Bits > struct floating_point { typedef ... hardware_type; // optional typedef ... emulated_type; typedef ... type; // hw, if available, emulated otherwise }; typedef floating_point< 32 >::type my_float32_t; Just some thoughts...
I'm not a user of Boost.Multiprecision, but maybe namespaces would do a better job in distinguishing the types? Injecting various tags into the type names feels like C-style.
Or maybe a trait to construct the necessary type:
template< unsigned int Bits > struct floating_point { typedef ... hardware_type; // optional typedef ... emulated_type; typedef ... type; // hw, if available, emulated otherwise };
typedef floating_point< 32 >::type my_float32_t;
Just some thoughts...
Lets not over complicate these :-) Actually I'm pretty sure these typedefs will be hardly ever used, but they're useful for exposition. John.
I'm not a user of Boost.Multiprecision, but maybe namespaces would do a better job in distinguishing the types? Injecting various tags into the type names feels like C-style.
When push comes to shove, the top layer of Boost.Multiprecision
pretty much boils down to types, and only types --- defined in the
namespace boost::multiprecision. It is convenient to type-define
some popular ones of these via typedefs.
So it may be en example for which long, yet unambiguous,
names might be better than clouding up boost::multiprecision
with additional, third-level namespaces or other more complicated
C++ mechanisms.
Chris
On Wednesday, November 6, 2013 11:06 AM, Andrey Semashev
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Wednesday, November 06, 2013 9:08 AM To: boost@lists.boost.org Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
Fine with me! Those are good names --- consistent with existing Boost style, easy to recognize, and unambiguous. Can we get a consensus on those names?
One other suggestion:
cpp_float32_t cpp_float64_t cpp_float128_t
which keeps the "cuteness" and link to the names of the hardware types, but the cpp_ prefix indicates it's a software emulation?
I think I like these a bit better - except that should they be
cpp_bin_float32_t cpp_bin_float64_t cpp_bin_float128_t
I know it's more to type, but it's important that they are recognised as a binary type?
I'm not a user of Boost.Multiprecision, but maybe namespaces would do a better job in distinguishing the types? Injecting various tags into the type names feels like C-style. Or maybe a trait to construct the necessary type: template< unsigned int Bits > struct floating_point { typedef ... hardware_type; // optional typedef ... emulated_type; typedef ... type; // hw, if available, emulated otherwise }; typedef floating_point< 32 >::type my_float32_t; Just some thoughts... _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
One other suggestion:
cpp_float32_t cpp_float64_t cpp_float128_t
which keeps the "cuteness" and link to the names of the hardware types, but the cpp_ prefix indicates it's a software emulation?
I think I like these a bit better - except that should they be
cpp_bin_float32_t cpp_bin_float64_t cpp_bin_float128_t
I know it's more to type, but it's important that they are recognised as a binary type?
Those are rather similar to: cpp_bin_float_50 cpp_bin_float_100 to me, which have their digit counts in base 10.
Is double always 64 bit and float always 32? And quad isn't a float-point type yet?
It may be long double on some platforms. Still painting the bike shed yours, John.
I think I like these a bit better - except that should they be
cpp_bin_float32_t cpp_bin_float64_t cpp_bin_float128_t
I can go with those, too. They are also good names.
Sincerely, Chris.
On Wednesday, November 6, 2013 10:53 AM, Paul A. Bristow
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Wednesday, November 06, 2013 9:08 AM To: boost@lists.boost.org Subject: Re: [boost] [multiprecision] Radix-2 typedef naming convention
How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
Fine with me! Those are good names --- consistent with existing Boost style, easy to recognize, and unambiguous. Can we get a consensus on those names?
One other suggestion:
cpp_float32_t cpp_float64_t cpp_float128_t
which keeps the "cuteness" and link to the names of the hardware types, but the cpp_ prefix indicates it's a software emulation?
I think I like these a bit better - except that should they be cpp_bin_float32_t cpp_bin_float64_t cpp_bin_float128_t I know it's more to type, but it's important that they are recognised as a binary type? Is double always 64 bit and float always 32? And quad isn't a float-point type yet? Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Oh yeah. You're right again, and I flubbed up again. Thanks.
How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
Fine with me! Those are good names --- consistent with existing Boost style, easy to recognize, and unambiguous. Can we get a consensus on those names?
Unless there are strong objections I plan to go with those names - also merge all the code to SVN Trunk fairly soon. Rationale: 1) The types aren't actually 32/64/128 bits in size, merely emulating types that are. 2) The cpp_bin_float128_t names are too close to the decimal-digit names for comfort (ie potentially confusing). 3) Other than quad precision, I doubt many folks will use these anyway, so lets just paint the bike shed and be done with it ;-) John. PS to Paul (and anyone else interested): can I get you look at the revised numeric_limits docs as I've made some changes to your original draft: https://svn.boost.org/svn/boost/sandbox/multiprecision.cpp_bin_float/libs/mu...
How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
Fine with me! Those are good names --- consistent with existing Boost style, easy to recognize, and unambiguous. Can we get a consensus on those names?
Unless there are strong objections I plan to go with those names - also merge all the code to SVN Trunk fairly soon.
OK, great. Sounds fine.
I keep using cpp_bin_float off-and-on. I have not encountered
any problems. I would like to look at overflow / underflow
for add, sub, mul, div. In addition, I find that the performance
drops way down as the digit count increases --- even worse than
cpp_dec_float. But this old hat and not relevant regarding trunk.
(Because we already know that we need more advanced
multiplication routines if we want to support high digit counts.)
I think it's great that you took on radix-2 big float, John.
Thank you.
Sincerely, Chris.
On Sunday, November 17, 2013 1:01 PM, John Maddock
Oh yeah. You're right again, and I flubbed up again. Thanks.
How about: cpp_bin_float_single; cpp_bin_float_double; cpp_bin_float_quad;
Fine with me! Those are good names --- consistent with existing Boost style, easy to recognize, and unambiguous. Can we get a consensus on those names?
Unless there are strong objections I plan to go with those names - also merge all the code to SVN Trunk fairly soon. Rationale: 1) The types aren't actually 32/64/128 bits in size, merely emulating types that are. 2) The cpp_bin_float128_t names are too close to the decimal-digit names for comfort (ie potentially confusing). 3) Other than quad precision, I doubt many folks will use these anyway, so lets just paint the bike shed and be done with it ;-) John. PS to Paul (and anyone else interested): can I get you look at the revised numeric_limits docs as I've made some changes to your original draft: https://svn.boost.org/svn/boost/sandbox/multiprecision.cpp_bin_float/libs/mu...
participants (6)
-
Andrey Semashev -
Christopher Kormanyos -
Gavin Lambert -
John Maddock -
Paul A. Bristow -
Rob Stewart