Re: [boost] Infinite precision integer draft

From: Maarten Kronenburg (M.Kronenburg_at_[hidden])
Date: 2006-05-25 10:38:03

"Paul A Bristow" <pbristow_at_[hidden]> wrote in message
news:E1FjC7o-0000md-FX_at_he303war.uk.vianw.net...
>
>
> |  -----Original Message-----
> |  From: boost-bounces_at_[hidden]
> |  [mailto:boost-bounces_at_[hidden]] On Behalf Of Maarten
> |  Kronenburg
> |  Sent: 24 May 2006 18:29
> |  To: boost_at_[hidden]
> |  Subject: [boost] Infinite precision integer draft
> |
> |  In the boost vault
> |  http://boost-consulting.com/vault/
> |  under Math - Numerics the document
> |  infintdraft.pdf contains the
> |  Proposal for an Infinite Precision Integer
> |  for Library Technical Report 2, Draft.
> |  Any comments are welcome.
>
> 1  I wonder if the get_sign could not be sign_bit to comform to
> floating-point types.  I know that one could maintain there isn't a sign
bit
> (it's a byte or more).

Thanks for your comments.
I like the name get_sign more,
just like for example get_time.
Where did you find sign_bit?

>
> 2  If you have to write is_zero() instead of == 0,  will this make
templated
> code difficult?

The == 0 notation is always allowed, also in templates,
but it is a little slower than is_zero().
The == 0 generates a temporary integer with value zero,
by implicit converting constructor.
But in templates that also should work for template type
parameter int, the == 0 indeed must be used.

>
> 3  Is there a reason for starting with integer rather than unsigned
integer
> (which sounds simpler). Will deriving unsigned integer from (signed)
integer
> be less efficient that vice versa?

The unsigned integer is not simpler but
more difficult than the integer, because
the unsigned integer must do checks if
an addition or subtraction result is
negative.
So for unsigned integer a simple -- can
generate an exception.

>
> 4
>
> 2.3.1 Rationale
>
> The destructor is virtual so that derivation of class integer is possible.
>
> Should 'of' be 'from'?

Yes you are right, I will correct this.

>
> 5  Is there a reason why
>
> const integer x( "0x12345678901ABCDEF" ); is not implemented?
>
> when istream hex input is?

Yes you are right.
The base for the streams is controlled with the
basefield flag, but for the constructor from string
one can check if it begins with "0" or "0x" or "0X"
and set the base to 8 or 16 accordingly.
I will add this to the constructor from string and char *.

>
> 6  You might like to reference other widely used implementations like NTL?
>
> But this is long, long overdue as a Boost and Standard Library.
>
> Good luck!
>
> Paul
>
> ---
> Paul A Bristow
> Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
> [phone] & SMS, Mobile [phone] & SMS
> pbristow_at_[hidden]
>
>
>
>
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>