Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Barend Gehrels (barend_at_[hidden])
Date: 2011-03-06 09:22:52

Hi,

This is my second part of the review, now including a vote. Chad, thanks 
for all your answers on the first part.

On 5-3-2011 22:26, Chad Nelson wrote:
> On Sat, 05 Mar 2011 18:06:40 +0100
> Barend Gehrels<barend_at_[hidden]>  wrote:
>
>> This just came during writing this review:
>>
>>> The only competing library that matters, so far as I can see, is
>>> GMP.
>> I don't think this is the case. ttmath is really competing, header
>> only, templated, etc. I've mentioned ttmath various times on this
>> mailing list (e.g. here
>> <http://lists.boost.org/Archives/boost/2010/02/161943.php>  ).
> Apologies, I didn't join the mailing list until late March of last
> year, so I never saw that. I wondered why, when I asked for a
> preliminary review of XInt, someone made a comment about large-integer
> libraries all showing up at once.

Sure, we cannot read all mails. I didn't catch all mails about XInt and 
therefore probably didn't put ttmath into those threads.

> I hadn't seen ttmath before. From a quick glance, it looks very
> nice. I notice several differences between it and XInt, such as:
>
> * It stores numbers on the stack -- good for speed, bad only because
>    the stack might impose an upward boundary on the number of numbers
>    you can store.

That is indeed the case. I didn't wrote this yesterday, but if you 
select its template parameter too small, the results fail. That might be 
prevented (I don't know) but the code as I presented it just gives the 
wrong results. So in that sense, XInt behaves much better.

> * It has a compile-time-set limit on the magnitude of numbers, which
>    could be considered a plus (since logic errors in client code can
>    consume a LOT of memory under XInt before you can shut the program
>    down).
>
> * It has a floating-point component, which XInt presently lacks.
>
> * The stream support isn't quite as complete as XInt's.
>
> * It uses assembly language... good for speed, for a number of reasons,
>    but bad for portability to other hardware platforms without a pure C++
>    fallback.

That is indeed a drawback.

>> [...] About my vote, this is difficult. I would really like ttmath be
>> part of Boost. It has a BSD license. It is header only. Its floating
>> point numbers are really good and according to my own test better (in
>> precision) than either CLN or GMP. But ttmath is never submitted
>> until now and I don't know if it is still planned. Besides that, it
>> is not uncommon within Boost to offer two similar libraries.
> I see no conflict between them. ttmath is obviously better at some
> things, XInt at others. Though I think either of them could equal the
> other with a little more work.
>
>> xint::integer is one thing, xdouble::double is missing. Is any
>> floating point precision planned? If no, is it not inconvenient to
>> have two completely different libraries for integer and FP? I really
>> need a perfect Boost FP big number library...
> I'd planned on it (as mentioned in the second paragraph here:
> <http://www.oakcircle.com/xint_docs/zero.html>), either myself or
> helping a GSoC project aimed that way.

Good to know.

> But if the author is willing to
> proposed ttmath to Boost, I wouldn't be at all disappointed to
> concentrate on the integer side of things. That's where my main
> fascination lies.
>

Yep, I definitely hope that there will be a FP counterpart too, written 
either by you or with your help, of by the ttmath author, or both of 
you. But the scope of this review is integer.

>> So I didn't decide about my definitive vote yet.
> Regardless of your final decision, thanks for reviewing it. But of
> course, I hope you decide in XInt's favor. :-)

And now my final decision, I vote for YES for inclusion of XInt into Boost.

The doubts I had yesterday were mainly about ttmath, but voting no 
because of a library which might ever been reviewed, or maybe never, and 
is not better in all aspects, seems now senseless to me. I think XInt is 
a very useful library. The author has indicated to solve some issues 
such as virtual inheritence -> CRTP, and maybe COW, as described in many 
other mails. I think the performance, currently acceptable, will profit 
from that (to some extent).

In summary, I think XInt will be a valuable addition to the Boost 
collection.

So thanks again for writing this library and submitting it for review.

-- 
Barend Gehrels
http://about.me/barendgehrels