
Boost : 
From: Philippe Mori (philippe_mori_at_[hidden])
Date: 20050907 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 builtin
type, this can be very interesting.
In some case, it might be ok for us to convert to builtin 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk