overflow in mpz type with a simple mpz_add_ui

[Torbjörn Granlund]

Vincent Lefevre <vincent at vinc17.net> writes:

  This is not properly documented, then. The manual says:

       'mpz_add_ui', 'mpz_sub_ui', 'mpf_add_ui' and 'mpf_sub_ui' benefit
       from an in-place operation like 'mpz_add_ui(x,x,y)', since usually
               ^^^^^^^^^^^^^^^^^^
       only one or two limbs of 'x' will need to be changed.  The same
       applies to the full precision 'mpz_add' etc if 'y' is small.  If
       'y' is big then cache locality may be helped, but that's all.

  Since this should be an in-place operation (as there is no carry),
  an overflow is unexpected here.

Overflow here is a result of the mathmatical result.  Whether things are
done "in place" or not is not part of it.

But overflow might be flagged one limb too early for addition; instead
of at 2^27-1 limbs for 32-bit hosts it might happen already at 2^27-2
limbs.  I cannot say that's particularly bad.

As it happens, overflow detetion for other cases is much more coarse,
such as powering.

-- 
Torbjörn
Please encrypt, key id 0xC8601622