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 <stdfloat.h> and <cstdfloat>, respectively. So you are right. It would seem to be very confusing to have: boost::multiprecision::float32_t (a multiprecision type) *and* boost::float32_t, std::float32_t, and float32_t (all type-defined to the same built-in type). Doesn't this essentially rule out my original suggestion? I think so. 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 Rational: * This convention is consistent with John's original intent of providing the number of radix digits as a template parameter.* It is consistent with the existing naming convention already established for decimal multiprecision types already present in Boost (i.e., cpp_dec_float_50, cpp_bin_float_100). * It avoids potential naming ambiguities with future type definitions such as float32_t, etc. that may also end up in the boost namespace, as well as the global and std namespaces. That all seems pretty good to me. Any opinions? Sincerely, Chris. On Monday, November 4, 2013 5:22 AM, Gavin Lambert <gavinl@compacsort.com> wrote: 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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost