mpn_invert implementing ApproximateReciprocal.

Torbjorn Granlund 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.

-- 
Torbjörn


More information about the gmp-devel mailing list