Boost logo

Boost :

Subject: Re: [boost] Name and Namespace for Potential BoostExtended Floating-Point
From: John Maddock (boost.regex_at_[hidden])
Date: 2011-09-01 06:38:49

> 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.

> 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

I suspect this may depend on the data type - for real-valued types, I've
done some experimenting with a port of the LINPACK benchmark to C++ that
shows *almost* no difference between expression template enabled code
(whether mine, or existing wrappers such as mpf_class) and more traditional
class abstractions. I need to do some experimenting and profiling, but it
seems like the runtime is completely dominated by the cost of
multiplication/division, and even though my code generates fewer temporaries
that either mpf_class or traditional non-ET wrappers, that simply doesn't
take much off the runtime.

Of course LINPACK is an old Fortran program written in a very idiomatic
style that probably doesn't really stretch the expression template code at
all. So arguably we need better test cases - the special functions in
Boost.Math would make good candidates I guess.

> 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.

I take it you mean that within the "big number" class type initialized mpq_t
variables get cached and recycled?

That's an interesting idea, and not something I've investigated so far - not
least because of the issues you highlight.

One thing I do want to investigate for fixed-precision real-valued types
(with mpfr or mpf backends) is to eliminate the allocation altogether by
placing the storage directly in the class (if it makes sense for not-too
large precisions).

I have a couple of questions relating to the polygon library if that's OK?

* Is there a concept check program anywhere that I can plug my types into
and verify they meet the libraries conceptual requirements?
* Is there a good program for testing "big number" performance within your
library (for either large integers or rationals)?

And yes, we would very much like your input ;-)

With regard to expression templates, can I direct you to the "big_number"
directory of the sandbox and the wildly out of date docs at
In particular the conceptual requirements required for backend types are
constantly evolving - both as the needs of new backends are evaluated - and
as I come up with new "good ideas" ;-) Nonetheless I would much welcome
your input, and will try and add a rationale type backend ASAP for you to
experiment with.

Regards, John.

Boost list run by bdawes at, gregod at, cpdaniel at, john at