What you have is a variable precision type using fixed storage?
Yes you are right. However the functionality it provides is the same as with 2's complement backend. The reasons 2's complement representation is used for integral types (int32, int64) are: 1) it requires less storage, as doesn't use additional value to handle number of bits set. 2) it allows to execute addition and subtraction quickly on CPU (without considering different sign cases). For higher order fixed_int this speedup won't be notable, as you spend more time on adding limbs and doing shifts. Certainly looks like lazy evaluation of higher-order limbs is a big win in
this case - I'm guessing that most operations use only one or two limbs, and just every now and then you get a true big number?
Correct. That's why I keep insisting on the implementation from here http://svn.boost.org/svn/boost/sandbox/SOC/2007/bigint/boost/bigint<http://svn.boost.org/svn/boost/sandbox/SOC/2007/bigint/boost/bigint/bigint_default.hpp>. Wrapping it with a multiprecision interface will make it a very good bigint library I believe. However before doing that we should also investigate concerns around that library (I'll try to contact the author). Thanks, Andrii