mpn_invert implementing ApproximateReciprocal.
tg at gmplib.org
Mon Dec 14 20:49:18 CET 2009
bodrato at mail.dm.unipi.it writes:
> I prefer not to commit, when I'm aware of a test failed by the new code.
> I think that's a very wise principle! :-)
It depends. One of the acceptable behaviour for the "principle" above is:
"do commit before any test" :-)
> The measured BINV_NEWTON_THRESHOLD is probably too high because of this.
> You're right. Swapping the measurement order is also not right, as the
> code is written. I don't see how to do this easily, unless we assume
> mpn_mul will never be relevant here. I think I'll do that for now.
May I suggest an inelegant solution? Remeasure BINV_NEWTON_:
Ehum. It is easy enough to Do It Properly, adding a special speed
function to tuneup.c. Let's just wait a bit, there will be more usages
of mulmod_bnm1 soon which might need thresholds.
A MUL_TO_MULMOD_BNM1_2NXN_THRESHOLD will probably make sense, but it
should be used in binvert directly; only if it is greater than
BINV_NEWTON_THRESHOLD should the selection code be compiled in.
More information about the gmp-devel