Re: [boost] [mp_int] new release

Subject: Re: [boost] [mp_int] new release
From: Paul A Bristow (pbristow_at_[hidden])
Date: 2008-10-08 12:30:16

>-----Original Message-----
>From: boost-bounces_at_[hidden] 
>[mailto:boost-bounces_at_[hidden]] On Behalf Of Scott McMurray
>Sent: 08 October 2008 16:11
>To: boost_at_[hidden]
>Subject: Re: [boost] [mp_int] new release
>
>On Wed, Oct 8, 2008 at 11:01, Brandon Kohn <blkohn_at_[hidden]> wrote:
>> --------------------------------------------------
>> From: "Mathias Gaunard" <mathias.gaunard_at_[hidden]>
>> Sent: Monday, October 06, 2008 5:50 PM
>> To: <boost_at_[hidden]>
>> Subject: Re: [boost] [mp_int] new release
>>
>>> Kevin Sopp wrote:
>>>
>>>> I made a new release of my multiprecision integer library
>>>
>>> I personally find the words arbitrary precision or multiprecision
>>> ambiguous.
>>> I never know which one means that the numbers grow as 
>needed and which
>>> ones means that it can work with any size, but fixed

>> I have this same issue. From my tests I suspect his grows 
>arbitrarily. I
>> would propose a name change to reflect that. I'm sure this has been
>> discussed before. big_int seems popular if a bit crude. 
>Assuming it is
>> arbitrary, arbitrary_precision_int? (perhaps convenience 
>typedefs?) I tend
>> to prefer descriptive names to abbreviations; though I 
>concede I may be in the minority.

>I'm not a fan of that one, since LLVM has an "APInt" class which
>represents a fixed, but arbitrary, precision integer.
>
>How about unbounded_int?  It fits nicely with the is_bounded 
>in numeric_limits.

So are you proposing two names:

bounded_int - arbitrary but fixed (maximum?) size integer

unbounded_int - grows to accommodate a size (bounded only by machine memory).

As an aside, does this scale to floating-point?

If we were to produce a Boost equivalent to NTL quad_float bounded_float and RR - arbitrary but fixed (default 50 decimal digits)
and an unbounded Exact real,

for example to 

unbounded_float (or unbounded_real)

similar to exact real - but then exact_real would be more obvious?

and bounded_float or bounded_real

But then one wants to encode the real precision?  float, double, quad_float, octo_float...

Paul

---
Paul A Bristow
Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB
[phone] & SMS, Mobile [phone] & SMS
pbristow_at_[hidden]