DOC: Tweaks to fft documentation

[peterbell10]

This fixes the typos pointed out by @endolith in #10238 and updates the scipy.fftpack documentation to link to scipy.fft.rfft instead of the NumPy version.

[endolith]

Ok, https://github.com/scipy/scipy/blob/master/scipy/fft/_basic.py should be updated to mention that it uses Bluesteins's algorithm now?

Are the speed benefits of fft < rfft < dct still true?

[peterbell10]

Are the speed benefits of fft < rfft < dct still true?

• fft <= rfft is still true since rfft falls back to a complex bluestein transform for prime sizes.
• dct is still using fftpack so will be slower for prime sizes.

[endolith]

The 13× speedup example on https://13717-1460385-gh.circle-artifacts.com/0/html-scipyorg/generated/scipy.fft.next_fast_len.html is no longer correct, right?

It also says

(These are also known as n-smooth numbers, regular numbers, or Hamming numbers.)

"n-smooth" applies to any n, of course, but "regular numbers" and "Hamming numbers" only applies to 5-smooth. https://en.wikipedia.org/wiki/Regular_number

[peterbell10]

I redid the timings with pypocketfft. Fftpack was something like 600x slower and that was for a much smaller transform.

[endolith]

Also the references are formatted strangely on https://13717-1460385-gh.circle-artifacts.com/0/html-scipyorg/generated/scipy.fft.fft.html#id4 but I think the markup isn't to blame?

On https://13717-1460385-gh.circle-artifacts.com/0/html-scipyorg/generated/scipy.fft.rfftfreq.html
the "(but like scipy.fftpack.rfftfreq)" remark could probably be removed

[endolith]

Fftpack was something like 600x slower

I don't mean pocketfft vs fftpack, I mean pocketfft with a prime size vs a power of 2 vs a n-smooth size, as in the example text

[peterbell10]

On 13717-1460385-gh.circle-artifacts.com/0/html-scipyorg/generated/scipy.fft.rfftfreq.html
the "(but like scipy.fftpack.rfftfreq)" remark could probably be removed

The fftfreq functions are all imported directly from numpy.

I don't mean pocketfft vs fftpack, I mean pocketfft with a prime size vs a power of 2 vs a n-smooth size, as in the example text

Yes, that's what I meant as well. fftpack's next_fast_len docs show the prime size as 630x slower than the next_fast_len size.

I retimed everything in the example using scipy.fft, making the fft size much larger so that the difference was actually significant. Compare it with the fftpack version and the numbers are completely different.

[larsoner]

@endolith can you see if this addresses your concerns?

[endolith]

Well the description of speeds is still incorrect, right? Can that be updated? The Examples section in https://13717-1460385-gh.circle-artifacts.com/0/html-scipyorg/generated/scipy.fft.next_fast_len.html ?

[peterbell10]

Well the description of speeds is still incorrect, right? Can that be updated?

It's already up to date. Compare it to the fftpack docs:
https://13717-1460385-gh.circle-artifacts.com/0/html-scipyorg/generated/scipy.fftpack.next_fast_len.html#scipy.fftpack.next_fast_len

[endolith]

Oh, ok.