|
Boost : |
Subject: Re: [boost] [xint] Boost.XInt formal review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-03-05 16:26:22
On Sat, 05 Mar 2011 18:06:40 +0100
Barend Gehrels <barend_at_[hidden]> wrote:
> This is my little review of XInt. Thanks for creating this library.
And thank you for reviewing it.
>> - What is your evaluation of the documentation?
>
> The documentation is good. It seems complete and the texts are very
> readable. It contains enough samples to start using it. It contains
> enough reasoning. For an integer library, which you can normally
> start to use immediately, it is definitely good enough. Is it
> generated by Doxygen?
Yes, it's Doxygen. Sorry for the lack of attribution, that has already
been corrected for the next release.
> I've doubts about the inclusion of random generators within XInt. I
> consider it as out of scope.
It *is* out of scope. But they're only included for convenience, and
for use in the examples, they're not actually used in or by the library
itself unless the person using it explicitly feeds one of them to it.
> About Boost.Random, The documentation states "But, also as of Boost
> 1.43, it requires a compiled library", I don't have this impression.
> I always use Boost.Random by header only.
From
<http://www.boost.org/doc/libs/1_46_0/more/getting_started/unix-variants.html>
(and also on the Windows version of the same page):
"Boost.Random has a binary component which is only needed if you're
using random_device."
> 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.
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.
* 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.
* From the FAQ page, it looks like there's no documentation at present.
I didn't delve into the code, so I don't know what "extras" it includes
beyond a basic math class.
I can't really compare it apples-to-apples to XInt. It has a different
focus. Within that focus, I have no doubt that it's better than XInt...
just from the prose descriptions, I can tell that it would beat XInt's
current implementation in speed handily. But XInt has portability,
documentation, and probably "extras" (like primality testing). No clear
winner this round, try again after both have had another year to
mature. :-)
> There is also CLN ( http://www.ginac.de/CLN/ )
Hobbled by GPL licensing, and not header-only, but includes
floating-point support and a different set of "extras" (XInt doesn't
have things such as complex-number support built in), as well as
implementing better large-number multiplication algorithms. In a
head-to-head comparison, it probably beats XInt in almost every
category. The licensing problem is a killer though.
> [...] Just my summary is that XInt seems slightly slower than ttmath
> for me on gcc, and is about the same speed on MSVC 2005. So, for a
> brand new library written in five months (I'm referring to other
> mails now), I think the speed is acceptable or good.
XInt is only *slightly* slower that a library that uses assembly?! :-D
> [...] 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. 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.
> 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. :-)
-- Chad Nelson Oak Circle Software, Inc. * * *
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk