GMP 6 the incomatible GMP?

[Torbjorn Granlund]

Marc Glisse <marc.glisse at inria.fr> writes:

  Experimentally (for me, others can have wildly different use cases),
  what really helps for small nums isn't to save space, it is to not
  allocate at all, for instance storing a few limbs in the base type and
  only allocating when that's not enough (recycling storage can work
  even better, but is for very specific uses and may not make sense for
  a generic library). There are plans to add a bignum type to the C++
  standard, and people are discussing whether it should be part of the
  specification that constructing small numbers (not even just 0)
  doesn't use dynamic allocation. Now the target users of this bignum
  type and GMP are not exactly the same (bignum would be used a lot by
  people who only need int but want to be safe), so it makes sense if
  the best solutions differ.

I am sure this is often a god idea, perhaps it would be good also in
GMP.

My main reason for not originally doing it like that is code complexity.
Having three operands (thing mpz_add) each with two possible
representations, will give some alternative execution paths.

Another problem is mpz_t size.  It is currently 16 bytes on 64-bit
machines (and 12 bytes on on 32-bit machines).  Even if only one bit of
these bytes are used for typing, we ain't getting much headroom from the
remaining 127 and 95 bits, respectively.  Making the structures larger
is to costly.

-- 
Torbjörn