Re: [boost] Infinite precision integer draft

From: Maarten Kronenburg (M.Kronenburg_at_[hidden])
Date: 2006-05-31 16:24:31

This problem with unsigned_integer
throwing an exception when negative
is already apparent for the two
expressions
a-b
and
-a+b
When the integer binary operator-
would clone the lhs, then the second
effectively does a negate, but the
first does not.
Then the first would not throw an exception,
but the second would.
When because of this problem the
unsigned_integer goes, then the user
can only make an unsigned integer
by using the modular_integer and setting
its modulus (for example to 2^n).
But as this would limit the values
to under 2^n, it is not really
infinite precision anymore.
So we have a dilemma: or we have
a true unsigned infinite precision integer
which may or may not throw exceptions in
equivalent expressions, or we only
have an unsigned integer which is
actually a modular integer with a modulus,
so which is not really infinite precision.
But the modular_integer will be there
anyway, which may serve as an unsigned
integer by:
typedef modular_integer unsigned_integer;
Regards, Maarten.

"Maarten Kronenburg" <M.Kronenburg_at_[hidden]> wrote in message
news:e5k7bh$chh$1_at_sea.gmane.org...
> The situation is a little bit different.
> The integer binary operators like
> operator+ and operator- return
> an integer, so the type of these
> temporaries is integer.
> Each type derived from type integer
> has an
> operator=( const integer & )
> which converts the temporary integer
> back to the derived type.
> So after assigning the result, the
> result is identical.
> Then there are the temporaries
> that are cloned inside the
> integer binary operators,
> and the corresponding virtual
> member function is called of this clone.
> Because the binary operator must
> choose which object to clone,
> the rhs or the lhs, the values of these clones
> and the values of the integer temporaries
> can be different between
> a-b-c
> and
> a-(b+c).
> So the values of the clones and the integer
> temporaries can be different anyway,
> but as the unsigned_integer throws and
> exception when it becomes negative,
> the brackets may decide whether an
> exception is thrown.
> The question is if this can be accepted,
> if not the unsigned_integer must go.
> In the document I will also mention
> this issue.
> Regards, Maarten.
>
> "Maarten Kronenburg" <M.Kronenburg_at_[hidden]> wrote in message
> news:e5k67i$7hr$1_at_sea.gmane.org...
> > Because the integer binary operators
> > must clone the rhs OR the lhs,
> > the temporaries in expressions can be
> > of type integer OR derived type.
> > Now as each derived type has an
> > operator=( const integer & )
> > which turns the integer temporary
> > back to the derived type,
> > the result after assignment is always
> > identical.
> > But the temporaries can still be either
> > integer type or derived type.
> > This expression
> > a-b-c
> > can have another type of temporary then
> > a-(b+c)
> > However which type it is is independent
> > of compiler, because of the
> > [expr.add] remark.
> > Now the question is that because
> > unsigned_integer throws an exception
> > when it becomes negative,
> > is it acceptable that when a and b nonzero,
> > a-b-c
> > then throws an exception and
> > a-(b+c)
> > not?
> > Regards, Maarten.
> >
> > "Maarten Kronenburg" <M.Kronenburg_at_[hidden]> wrote in message
> > news:e5id0q$9ev$1_at_sea.gmane.org...
> > > There is however one catch to the
> > > unsigned_integer: the expression
> > > a-b-c
> > > Then look in [expr.add]:
> > > "The additive operators group from
> > > left-to-right".
> > > The integer binary operator-
> > > first clones the rhs, negates it,
> > > and then adds to it the lhs.
> > > This guarantees that when b or c
> > > are non-zero unsigned_integer,
> > > then ALWAYS an exception
> > > is thrown.
> > > BUT what about
> > > a-(b+c)
> > > Now (b+c) returns a temporary
> > > integer (not unsigned_integer),
> > > which is negated (NO exception)
> > > and a is added to it.
> > > So although the behaviour is
> > > compiler-independent because of the
> > > [expr.add] remark, the use of braces
> > > in expressions may change the
> > > behaviour of an unsigned_integer
> > > expression, that is while
> > > a-b-c
> > > may throw an exception,
> > > a-(b+c)
> > > may not.
> > > Regards, Maarten.
> > >
> > > "Maarten Kronenburg" <M.Kronenburg_at_[hidden]> wrote in message
> > > news:e5gvs8$jbm$1_at_sea.gmane.org...
> > > > 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.
> > > > 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.
> > > > 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.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Unsubscribe & other changes:
> > > http://lists.boost.org/mailman/listinfo.cgi/boost
> > > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Unsubscribe & other changes:
> > http://lists.boost.org/mailman/listinfo.cgi/boost
> > >
> >
> >
> >
> > _______________________________________________
> > Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
> >
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>