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.