Re: [boost] Multiprecision Review

Subject: Re: [boost] Multiprecision Review
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2012-06-24 21:47:16

From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]] On Behalf Of Christopher Kormanyos

>The culprit can only be.... the European Soccer Championships quarter finals!
>Double over-time and eleven meter, going Italy-England with both teams playing exceptional soccer!

My view is that the library is not very controversial.  If people had objections they would be coming out to say so.  If people were concerned it might not get accepted they would come out and give a positive review to help it along.  I think it is a good library, it has the abstraction in the right place (from my perspective) and it does what I need.  It addresses all of the things about xint that made that library unacceptable.  In particular it allows the user to specify the back end implementation and is compatible with Boost.Rational.  Perhaps if we want specifically 128bit and 256bit 2's complement big integers that emulate builtins of that size then those should be a separate library: boost::int128_t and boost::int256_t..  I welcome Phil to implement it.  This library's purpose isn't to provide the building blocks for providing those types.  This library's purpose is to provide an abstraction on numerical data types in general so that we can use them in boost and work toward standardization of them, which C++ does need.  It is very hard to provide a boost geometry library without access to a boost extended precision numerical data type.  Without this library we must implement our own or provide a metafunction to allow the user to specify at compile time a non-boost numerical type (as I have done.)  I'd much rather make my library default to boost::mp::number<rational...  instead of long double so that it is robust out of the box and then 99.9% of people would never need to use the mechanism to override with gmp because the lazy exact arithmetic I use makes the performance of the high precision numerical data type irrelevant.

We are all very busy people.  I've been working myself half to death lately.  I would have liked to try out the library with mine to make sure that everything hooks together satisfactorily and most importantly works correctly.  Testing the correctness of my algorithms using this numerical data type would be somewhat tedious, however, because passing tests is not proof of correctness.  I would need to be very thorough to make sure things were correct, and thorough is time consuming.  Right now I'm assuming the library will be accepted and planning to do that work later, since I should probably provide support for use of it once it has been released.

I've followed the entire review and discussion of the library from the first announcement up to now.  Everything I've seen leads me to feel that the library should be accepted, but this is not a review, just an opinion from an interested observer.  I'm particularly pleased to see that the library seems to have two motivated maintainers.  We know we can trust John, and I really like Christopher's energy.  It is a shoe- in for acceptance.

Regards,
Luke