Re: [boost] Interest in an arbitrary precision library?

From: Philippe Mori (philippe_mori_at_[hidden])
Date: 2005-09-07 18:11:39

IMO, we should have a few classes to handle most need without
to much overhead.

I thing we should support some policies :

A) Allocation
    - Fixed width (any multiple of 8 bit)
    - Variable width (dynamic memory)
    - Variable width (dynamic allocation) but with static allocation for 
small number.

B) Precision
    - Integer (multiple of one)
    - Rationnal (a numerator and a denominator)
    - Fixed (base 2 or 10 or maybe arbitrary).
        *** Base 2 would be faster as we would be able to do some shifting
            in many computations while base 10 would be usefull for number 
that
            are typically displayed to the user (currency, length, 
coordinates,...) at
            a given decimal precision.
    - Floatting (a mantissa and an exponent)
        *** This would be usefull to compress floatting point or have 
different
            ranges/precisions that standard one.

C) Signed or not

D) Computation of the error range or not

E) Handling of errors like overflow, NaN,...
    - Ignore
    - Special values like NaN, Infinity,...
    - Exceptions

F) Maybe the possibility to uses GMP for those who want it and can accept 
the licence.
    *** This would be optional (at least for most operation) and the speed 
should never
        be worst that twice as slow in worst case (or something like that).

Not all combination from A, B, C, D, E and F need to be supported. Also, we 
might
want to support some mixed type computations. In general, the uses of GMP 
should
not be required.

In my case, this thing that interest me the most is :

a) being able to support larger integer (64 or 128 bits) that are really 
fast for
additions and multiplications. They could be used to add a bunch of 32 bit
or even the product of two 32 bit integers (as a 64 bit integer) and not 
have
any overflow (or precision loss).

b) compressed floatting points (or integers) when the space matters (for
exemple on an handled). In our case, the handled store data that came
from a data logger that can record a few MB and we could a few data
logger active. Since these devices are slower and with limited memory,
if we can have compressed number that are almost as fast as built-in
type, this can be very interesting.

In some case, it might be ok for us to convert to built-in type at some
point in the computation. For example, we might do all accumulations
on large integers the uses floating point emulation of the device to
compute the final stats.

*** Another thing that would be interesting is to have some
performances comparisons on a variety of platforms so that
we can select the best type to uses more easily.