Add options to set the fft size and to normalize the ifft output; calculate the fft by default; and improve the documentation and the tests#3
Conversation
AngelEzquerra
changed the title
|
I wonder if there is a more optimum way to implement the "Add |
| for i in 0..<result.len: | ||
| result[i] = result[i] / complexInputLen | ||
|
|
||
| func fft*(input: openArray[Complex64], inverse: bool = false, normalize: bool = false, n = 0): seq[Complex64] = |
There was a problem hiding this comment.
regarding normalization, there are two kinds - 1/n and 1/sqrt(n) depending on what the numbers will be used for - see https://dsp.stackexchange.com/a/63006 and https://docs.scipy.org/doc/scipy/reference/generated/scipy.fft.fft.html#scipy.fft.fft
regarding n, this feels like outside of the domain of the fft function itself - it's a setLen away for anyone that wants to do fft this particular way (though they probably don't)
There was a problem hiding this comment.
I knew that scipy's fft had 3 normalization options. If you think that makes sense I can support them all by passing a norm argument that would be an enum.
Regarding n, I think it would be a good idea to support it as well, following scpy's API as much as possible.
There was a problem hiding this comment.
I've added norm arguments matching SCIPY's options plus a "disabled" option to completely disable the normalization. I've made the default backwards to mach SCIPY.
| input.toSeq & newSeq[Complex64](size - input.len) | ||
| elif size < input.len: | ||
| # Crop the input as much as needed | ||
| input[0..<size] |
There was a problem hiding this comment.
if n was pursued, this would introduce an unnecessary copy (that could be avoided with toOpenArray)
There was a problem hiding this comment.
You are right of course. I even mentioned in my first comment on this PR :)
I will look into it.
There was a problem hiding this comment.
I've improved the code to avoid unnecessary copies.
|
|
||
| let input = if size > input.len: | ||
| # Extend the input with zeros as much as needed | ||
| input.toSeq & newSeq[Complex64](size - input.len) |
There was a problem hiding this comment.
if n was pursued, setLen here would involve fewer copies and zeroings
There was a problem hiding this comment.
I've improved the code to avoid unnecessary copies.
| # Crop the input as much as needed | ||
| input[0..<size] | ||
| else: | ||
| input.toSeq |
There was a problem hiding this comment.
and another copy here - adding these copies up would significantly slow down the implementation - you should see this if you run the benchmark before and after
There was a problem hiding this comment.
FWIW, I ran the benchmarks and I did not notice any significant differences, but I agree that unnecessary copies should be avoided.
There was a problem hiding this comment.
I've improved the code to avoid unnecessary copies.
AngelEzquerra
force-pushed
the
normalize
branch
2 times, most recently
from
60a90e4 to
c60fee6
Compare
The argument name has been chosen to emulate the numpy.fft API.
…ler than the input.
…to match the scpy normalization feature API). The default normalization is set to `backward` to match the scpy behavior. This commit also adds tests for the different normalization modes.
This makes the fft and ifft functions use the same argument order, as well as making this library match scpy's fft argument order.
AngelEzquerra
force-pushed
the
normalize
branch
from
8b6e4f0 to
be5daef
Compare
2 participants
This PR does a few small things:
nargument to make it possible to choose the FFT size (it still uses the input length by default).