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@xs4all.nl> 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