Re: [boost] Name and Namespace for Potential Boost Extended Floating-Point

Subject: Re: [boost] Name and Namespace for Potential Boost Extended Floating-Point
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-08-31 13:46:02

Mostafa wrote:
> On Tue, 30 Aug 2011 12:08:46 -0700, Christopher Kormanyos
> <e_float_at_[hidden]> wrote:
> 
>> Hello,
>> 
>> We are seeking a good name for a potential boost extended precision
>> floating-point library. This is a multiple precision floating-point
>> type which *behaves* well in C++.
> 
> <snip>
> 
>> In order to continue, we need a good name for a potential boost
>> multiple-precision floating-point type.
>> 
>> For the multiple-precision real type we have names like:
>> 
>> 	* multiprecision_real
>> 	* mp_real
>> 	* extended_float_tOur current favorite is the second:mp_real.
>> 
>> For namespaces, we have:
>> 
>> 	1. boost::mp::mp_real
>> 	2. boost::multiprecision::mp_real
>> 	3. boost::multiple_precision::mp_realOur current favorite namespace
>> is number 2: boost::multiprecision.
>> 
> 
> <snip>
> 
>> 
>> Thank you. Sincerely, Chris.
> 
> If you're already in namespace mp, multiprecision, etc ..., then why
> prefix entities in that namespace with "mp_"?
> 
> Mostafa

Please don't call it real.  An mp float type is not at all a real number any more than a regular float type is a real number.  With extended precision floating type you cannot represent irrationals and you cannot represent most rationals exactly either.  What it is is a floating point type with a variable, but still finite number of bits.  All computers have finite sized memory and are required to run programs in a finite ammount of time.  That is why these numerical types are properly called multiple precision and not infinte precision.  I'd like to see the name be mp_float.  I prefer:

mp_float
mp_int
mp_rational

Obviously we need the mp_ prefix if we use float and int since these are keywords without it.  Also, if the user puts using namespace boost::multiprecision then they will benefit from the prefix.  I prefer multiprecision to mp since the library name I'm guessing would be multiprecision and it is conventional to have the namespace be the same as the library name.

For me the rational data type is very important and should wrap the gmp mpq_type.  It would be nice if the library could use mp_int with Boost.Rational to implement its own standalone mp_rational datatype, but I would prefer to use the gmp type whenever possible.

By the way, I have put extensive thought into how to build a good expression template system for dealing with multi-precision arithmetic and would like to be involved in some of the discussion of the design of the system.  Particularly, the most important thing about providing expression templates for multi-precsision is eliminating allocations and deallocations.  The allocations can easily dominate the runtime of a multiprecision algorithm.  There are many options and considerations for how to optimize the allocations, such as object pools, thread safety etc.  Anyone who uses multiprecision numerical data types in the same way they would use built-in numerical data types is writing code that runs significantly slower than the equivalent C code that doesn't abstract away allocation and deallocation and forces the programmer to choose where and when to allocate so that they choose the proper place.  I saw large speedups in my Polygon library by recycling gmpq_type variables rather than declaring them in the inner most scope in which they were used.

Thanks,
Luke