-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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
base: master
Are you sure you want to change the base?
Conversation
I wonder if there is a more optimum way to implement the "Add |
src/fftr.nim
Outdated
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
src/fftr.nim
Outdated
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if n
was pursued, this would introduce an unnecessary copy (that could be avoided with toOpenArray
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've improved the code to avoid unnecessary copies.
src/fftr.nim
Outdated
|
||
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if n
was pursued, setLen
here would involve fewer copies and zeroings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've improved the code to avoid unnecessary copies.
src/fftr.nim
Outdated
# Crop the input as much as needed | ||
input[0..<size] | ||
else: | ||
input.toSeq |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've improved the code to avoid unnecessary copies.
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.
8b6e4f0
to
be5daef
Compare
This PR does a few small things:
n
argument to make it possible to choose the FFT size (it still uses the input length by default).