Re: [boost] Infinite precision integer draft

From: Carlo Wood (carlo_at_[hidden])
Date: 2006-05-30 11:47:23

On Tue, May 30, 2006 at 10:31:01AM +0200, Maarten Kronenburg wrote:
> If you don't mind I start a new thread here.
> The unsigned infinite precision integer is
> different from the base type unsigned int,
> which is actually a modular integer with
> modulus 2^n.

I'm not convinced that unsigned_integer is needed.
It's only benefit would be that operator- and the
unary negation aren't defined, helping the user
to realize some possible glitches during compile
time.  However, if someone makes the mistake to
use subtraction anyway (which should return a
normal integer if it existed) then I don't think
that was a typo.

So, apparently, you want to support unsigned_integer's
for which subtraction IS defined, so you can do:

unsigned_integer x = 8;
x -= 3;

Then what is the use of it being unsigned? If the
result becomes negative then it doesn't exist.
Is it really useful to have an exception being thrown
in the case operator- or operator-= results in a
negative value?

We (at least, someone on this list, and I agree)
concluded that negation shouldn't be defined for
unsigned_integer because of unnecessary overhead.
I think the same argument holds for subtracting
two unsigned_integer's. It isn't worth the try{}catch
overhead: if it can become negative and you don't
want that - then use normal integers and simply
test if the result is < 0!

> Therefore two integer derived classes are
> needed: unsigned_integer and modular_integer.
> The unsigned_integer is an infinite precision
> integer which can only be positive or zero.
> The negate() of a non-zero unsigned_integer
> will always throw an exception.
> A subtraction which results in a negative value
> will do the same; therefore in my opinion
> there is no fundamental problem with this,
> as negation is subtraction from zero.

Well, if unsigned_integer has to be there, then
I guess this is what makes most sense.

> The modular_integer has a static method
> static void set_modulus( const integer & ).
> When the modulus is not set, it is zero,
> in that case the modular_integer is identical to integer.
> Users that like an unsigned integer with
> a negate() that always works, will have to
> use a modular_integer and set its modulus
> to a positive value.
> In the document I will specify unsigned_integer
> and modular_integer, and thus implementations
> can provide them.
> Regards, Maarten.

Except for possible overhead of too many tests
in relatively simple operations, I think this is
a (mathematically) sound design.  I hadn't realized
before that you made a difference between
modular_integer and unsigned_integer. I thought you
was using unsigned_integer to implement modular
integers :p (I guess I joined the thread too late).

-- 
Carlo Wood <carlo_at_[hidden]>