wrap-around interface

[bodrato at mail.dm.unipi.it]

Ciao Paul, and hi GMP-ECM developers!

Il Gio, 18 Ottobre 2012 11:06 am, Zimmermann Paul ha scritto:

>> > void mpn_mulmod_bnm1 (mp_ptr rp, mp_size_t rn, mp_srcptr ap, mp_size_t
>> an,
>> >                       mp_srcptr, bp, mp_size_t bn, mp_ptr tp)
>> > Multiplies {ap, an} by {bp, bn} mod B^rn-1 where B=2^mp_bits_per_limb,
>> > and stores the result into {rp, rn}. The scratch space tp is either
>> NULL,
>> > in which case the function allocates itself the needed memory, or it
>> should
>> > contain at least 2*rn+4 limbs (or the number of needed limbs should be
>> > documented).

> Then I suggest removing the tp argument

Then I think we should write a wrapper to the current internal function,
not only to deal with scratch space, but for the reason that it has some
more limitations than the interface you propose.

Eg. the current implementation requires rn >= an >= bn > 0, and an + bn >
rn/2.
Moreover, if an + bn < rn, the result is stored in {rp, an+bn} (the
remaining limbs are not zeroed).

In particular there is a detail that should be specified in a public
interface: the representation of the class [0] = [B^rn-1]. The comment to
the current internal function reads:

 * The result is expected to be ZERO if and only if one of the operand
 * already is. Otherwise the class [0] Mod(B^rn-1) is represented by
 * B^rn-1.

I.e. both representations are used. Does this "ambiguous" behaviour fit
the public interface you have in mind?

Regards,
Marco

-- 
http://bodrato.it/