Re: [boost] Name and Namespace forPotential BoostExtended Floating-Point

Subject: Re: [boost] Name and Namespace forPotential BoostExtended Floating-Point
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-09-02 04:07:24

>>> 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.
>>
>> Support for mpq_t is on my (long) todo list.
>
> I'm glad to hear.  In theory a fixed precision floating point type with 
> 128 bits or more in the mantissa would also satisfy my needs, but I have 
> only tested with multi-precison rational.

Nod.  In theory it should be possible to compose the low level GMP functions 
to create a fixed-precision (modulus arithmetic) integer type... but that's 
one for the future.

I do have a rational/mpq backend for big_number (or whatever we call it) 
now, but I'm away for a week now, so it might not get committed for a while 
:-(

> Gmp mpq_class expressions allocate for temporaries in compound 
> expressions.

Nod, one thing I've worked hard on is eliminating temporaries inside 
expressions whenever possible, so if you write say:

a = b + c + d + e + f;

Then you get no temporaries at all - everthing gets accumulated inside 
variable a.

However, something like:

a = b*c + d*e;

does require one temporary for *one* of the multiplications (the other uses 
"a" as working space).

One thing I've thought of is walking the expression tree at compile time to 
calculate the largest number of temporaries in the longest "branch", then 
creating these as an array at the outermost level of the expression 
evaluation and passing them down, so that:

a = b*c + b*d + b*e + b*f;

still only needs one temporary - which gets reused for each branch.

This needs some more thought though - to make sure I don't shoot myself in 
the foot and reuse something that shouldn't be!

>> * Is there a concept check program anywhere that I can plug my types
>> into
>> and verify they meet the libraries conceptual requirements?
>
> Not exactly.  I considered writing one, but basically what you need to do 
> is make sure the traits for your type are defined and that it is 
> registered as the right concept type then write a test that exercises the 
> traits through the free function of the same name that expects the concept 
> type.  For example point concept has get and set free functions that 
> exercise the get and set traits.  If those two functions work correctly 
> (and construct()) then your point is a model of the concept.  If you 
> copy-paste the example code for mapping a user defined type to the concept 
> and replace my type with yours and compile the test is part of the example 
> code because I exercise the traits.
>
>> * Is there a good program for testing "big number" performance within
>> your library (for either large integers or rationals)?
>
> If you look at the gmp_override.hpp you will see how I abstract away the 
> gmpq_class as a high_precision_type<> metafunction lookup.  You can 
> replace gmpq_class with anything you want and benchmark.  However, you 
> will find that the performance of the high precision type is almost 
> irrelevant to performance of the larger algorthm because lazy-exact 
> arithmetic implies that it is very rarely if ever used.  What you can do 
> instead is dig into my polygon_aribtrary_formation.hpp in details and find 
> the function that computes the intersection point of two line segments 
> using the high precision type.  You can then write a benchmark that 
> generates random line segments and intersects them.  Once you have that 
> working you can swap in different high precision types by replacing 
> gmp_override.hpp with your own override header file that you include just 
> after polygon.hpp and before your own benchmark code.  I have a "fitness" 
> test for intersection points so you can also use the benchmark code
>  as a stress test for the numerical data type chosen to see if it would 
> provide robust execution of my algorithm.  You will see the fitness test 
> applied at the end of the lazy version of line segment intersection just 
> before it conditionally calls the exact version.

OK sounds like that might not be as simple as I'd hoped, will investigate as 
I get time,

Regards, John.