Re: unexpected rounding behaviour of mpf_add(). bug?

[Kevin Ryde]

Frederik Schaffalitzky <address@hidden> writes:
> 
> Yes, I found out by looking through the sources, although to me it looks
> as if what is really happening is not excess precision on the end of "a"
> but truncation during the addition. All my operands have precision
> (_mp_prec) 3

Yes, if you ask for 64-bits on a 32-bit limb, then 3 limbs are used
(because the high limb is only a non-zero value).

> but the square root has size (_mp_size) 4, i.e. it uses the
> full mantissa available for that precision.

Yes, it uses the full prec+1 space, but just 3 limbs would have
sufficed.  Hmm.  Maybe it should only generate 3 limbs, since the 4th
is not needed for the requested precision.

> In the addition routine, the
> least significant limb is discarded before it is detected that the smaller
> operand was completely cancelled when lining up the exponents so the
> result ends up having only three limbs of precision (which is less than
> the 64 bits that I asked for).

No, I believe 3 limbs make up 64 bits.

> It puzzles me that although the number of
> limbs allocated is always _mp_prec + 1, often this full mantissa is not
> used (being one limb less).

If you're adding 3 limbs to 3 limbs (same exponent), then there can be
a carry, so you need a 4th limb to store it in.  The alternative would
be, on finding a carry, to move the high 2 of the sum down to make
room, but it's more efficient to not do that, rather store 4 limbs and
let the next routine using that value take just 3 if that's all it
wants.

> However, I did find one way to
> solve my problem, which was to zero out the least significant limb of any
> mpf_t for which _mp_size == _mp_prec + 1. Since the addition routine does
> that anyway, not much is lost... :)

Yes, that should work, and never lose any bits needed for the desired
precision.  Bear in mind that this is outside the documented features
and hence not guaranteed to be compatible with future releases, etc,
etc.  (Though in reality big changes in that area are unlikely.)