Re: [boost] [bigint] Integer data type larger than 64 bits?

From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2008-08-20 21:05:02

Kevin wrote:
>there is no such library in the boost tree yet. I'm working on one and
>since this library hasn't been proposed for review yet, I'd suggest to
>factor this dependency out as a template parameter in your source if
>that is possible in a convenient way.

It is easy for me to make the high precision data type a member of
coordinate_traits that defaults to same type as is used to store the
result of an area computation, but can be specialized to any user
defined data type.  That would factor the dependency out, as you say.
Perhaps I should provide meta-function for this instead of traits....

I took a look at your linked source and there were quite a few files
there.  Which ones pertain to large integer types.  mp_int.h appeared to
be the class that provides high precision integer arithmetic, providing
infinite/variable precision arithmetic on an array of digit values, with
support for negative numbers.  Can your digit_type be 64 bit unsigned
integer?  If so you have pretty much the ideal variable precision
integer.

--snip--
private:
  digit_type* digits_;
  size_type used_, capacity_;
  int sign_;
};
--end snip--

Why not simply use std::vector<digit_type, Allocator> instead of
managing your own array?

mp_int is actually overkill for my immediate problem, but would
certainly do the job and allow me to make a general solution.  It looks
like something we need in a place like boost.

I managed to solve my immediate problem by distributing division and
recovering the lost precision due to truncation with modulus operations.
I had to use 64 bit unsigned integers with associated sign stored in a
separate integer to perform hastily hacked up 65 bit signed arithmetic.
I used this to compute the product of deltas between signed 32 bit
integers and work with those values to eventually compute the
intersection of two line segments in a way that is robust to overflow
and truncates the result minimally and predictably.

When do you think your mp_int library will be ready for review?  I have
to provide a solution internally within a month or so and plan to submit
the geometry library to boost once completed, probably around end of
year.

Luke

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost