Re: wrap-around interface
Dear Marco,
Date: Sat, 20 Oct 2012 17:31:33 +0200 (CEST)
From: bodr...@mail.dm.unipi.it
Ciao Paul, and hi GMP-ECM developers!
ciao!!!
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).
this is fine. We won't use the wrap-around trick for an+bn rn.
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?
no, I thought about the classical non-redundant representation 0 = r B^rn-1.
Indeed a wrapper function makes sense.
Paul
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: wrap-around interface
Zimmermann Paul paul.zimmerm...@loria.fr writes:
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).
To find out the needed scratch space, you should use
mpn_mulmod_bnm1_itch. Scratch need is going to change if/when the fft
code (or general multiplication) is converted to an itch/scratch
interface.
If we make this interface public, should we advertise itch/scratch, or
should we keep that detail internal, and require applications to always
pass tp == NULL?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
Re: wrap-around interface
Niels,
From: ni...@lysator.liu.se (Niels Möller)
Date: Thu, 18 Oct 2012 10:43:34 +0200
Zimmermann Paul paul.zimmerm...@loria.fr writes:
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).
To find out the needed scratch space, you should use
mpn_mulmod_bnm1_itch. Scratch need is going to change if/when the fft
code (or general multiplication) is converted to an itch/scratch
interface.
If we make this interface public, should we advertise itch/scratch, or
should we keep that detail internal, and require applications to always
pass tp == NULL?
Regards,
/Niels
good remark. I propose applications always pass tp == NULL.
Then I suggest removing the tp argument to make the user interface simpler.
Paul
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel
