From: Kevin Sopp (baraclese_at_[hidden])
Date: 2008-03-31 10:55:01
On Mon, Mar 31, 2008 at 3:57 PM, Paul A Bristow <pbristow_at_[hidden]> wrote:
> Of course, this is interesting in that Boost 'needs' an arbitrary precision arithmetic package in its library.
I'm glad that you see its value, I got a little worried after no one
proposed a bigint library for GSoC this year ;-) My original
motivation for starting this library was that I need it to add
anything more interesting to the crypto library. And then I found
libtommath which made it easy to write a bigint library in a short
amount of time. Although there are many differences now between my
code and his.
> I have not looked at this in detail but it looks promising for the integer requirements. I am not qualified to judge the
> compromises between design and efficiency, as mentioned by Maarten Kronenburg, but this library seems to fit in with the header-only
> and template/container design used by most Boost libraries.
It was my intent to design it in a way that could be standardized.
> But there have been several unfinished big-integer attempts and I think you need to say why you think this one is better/more nearly
I have not seen other attempts except for big_radix_whole.tar.bz2 in
the vault which implements arbitrary precision unsigned integers. One
large advantage of my code is that it is quite simple, which makes it
easy to understand and maintain. Now I want to work on
polishing/finishing this library and then report back when it is
basically ready for review.
> However it does not address the floating point needs - yet.
> In order to be *really* useful, a 128 (and perhaps 256) fixed precision, and an arbitrary precision floating-point library is also
> needed, and preferably for better speed also a 128, and perhaps 256 fixed precision). But perhaps you are tired from your work so
> far ;-) Google Summer of Code project?
Luckily, Tom Denis, the author of libtommath has already written an
arbitrary precision floating point package - again all code is in the
public domain. Though he writes that it is not done yet it sounds like
a good starting point for an mp_float type. Personally, I don't have
any interest at the moment to start this project, I have other things
on my TODO list.
> PS (A cosmetic detail is that none of the files include the Boost License but that will be easily fixed. It might be desirable to
> have an explicit agreement to these terms for any of Tom's C code used or referenced too.)
This is by design as all code and documentation I wrote for this
library is in the public domain in the spirit of libtommath.
> PPS A check of your simplest demo program worked MSVC 2003, but produced an off-putting and worrying blizzard of warnings even at
> the default level 3 - these could (and should) be easily fixed by explicit casting.
Okay, I have only tested the code with gcc. Can you send me your
compiler output privately?
Thanks for your feedback it gives me the right motivation to continue
with this library.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk