According to the documentation for mpn_mul_fft:
/* put in {op, pl} the product of {n, nl} * {m, ml} mod (B^pl+1)
where B = 2^GMP_NUMB_BITS. */
This is essentially the function of the new:
int
mpn_mulmod_Bexpp1_fft (mp_ptr op, mp_size_t pl,
mp_srcptr n, mp_size_t nl,
mp_srcptr m, mp_size_t ml)
An example of its use is lines 87-89 of mpn/generic/inv_div_qr_n.c in MPIR.
I couldn't imagine this taking more than 10 mins of someone's time to
fix, given this information.
Note that for ~ 2500-11000 limbs (or maybe half this size for this
particular function), the GMP-ECM developers might notice a small
*slowdown*. But past this range, the new FFT should outshine the old
one substantially. This slowdown will be rectified in a later release
and is not, as far as I am aware, significant (should be < 5% I
think). This is of course assuming that we did the integration of the
new FFT without any regressions, which I admit I have not had time to
benchmark yet.
Bill.
On 15 October 2012 13:46, Brian Gladman <b...@gladman.plus.com> wrote:
> -----Original Message----- From: Bill Hart
> Sent: Monday, October 15, 2012 12:20 PM
>
> To: mpir-devel@googlegroups.com
> Subject: Re: [mpir-devel] MPIR 2.6.0-alpha2 released
>
> On 15 October 2012 09:12, Brian Gladman <b...@gladman.plus.com> wrote:
>>
>> -----Original Message----- From: Bill Hart
>> Sent: Monday, October 15, 2012 3:22 AM
>> To: mpir-devel@googlegroups.com
>> Subject: Re: [mpir-devel] MPIR 2.6.0-alpha2 released
>>
>>
>> Unfortunately, GMP-ECM will have to be rewritten to use the new FFT.
>>
>> Fortunately, the best_k and next_size stuff is no longer needed. So
>> this shouldn't be too much work.
>>
>> =========================
>> Doesn't this break the GMP compatibility mode?
>
>
> No. The FFT is undocumented.
>
> ==========================
>
> Thanks - I hadn't realised that. It seems that GMP-ECM imports part of
> gmp-impl.h and relies on GMP internals. Although it's not our job to fix
> this, I am still of the view that we should do what we can to help.
>
>
>> Can the old calls be mapped to the new FFT interface - that is dummy calls
>> for not needed items and a mapping from the old FFT call to the new one?
>>
>
> No, the operation of the new fft is just different.
>
>> This might be inefficient but it would be better than nothing until
>> something better can be arranged.
>>
>> In any event, we surely need to offer advice on what to do to use the new
>> FFT in place of the old one - maybe we already do this in the 2.6.0
>> manual?
>
>
> The example of the MPIR code that uses the FFT code for
> inverse/division should be sufficient to see what is needed here.
>
> ================================
>
> Ok but we need someone who is familiar with both the old and the new FFT
> interface to take a look at this.
>
> GMP-ECM has a significant user community so I hope that someone can pick
> this up.
>
>
> Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To post to this group, send email to mpir-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> mpir-devel+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
