You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In line 28, whoever originally wrote this expressly went out of their way to avoid using y = similar(x). I can't seem to find any discussion as to why this was done except for the vague comment, but I'm currently trying to interface with AbstractFFTs and this would be a huge minus for me.
Currently, I'm respecting whatever type the user inputs. While just plugging in AbstractFFTs would likely work just fine, I think this behavior could be undesirable. For example, right now, using StaticVector as both input and output accelerates the algorithms tremendously, which is particularly consequential when performing many very small FFTs. I asked @ararslan about this a few weeks ago, and got the response that this was ported over from when AbstractFFTs was in Base. Is it still necessary to do this?
The text was updated successfully, but these errors were encountered:
It's not necessary, but if it is used with FFTW.jl then it will cause an extra array copy to be allocatedd for cases where similar produces a non-StridedArray. That can be eliminated, however, by adding more specialized methods to FFTW.jl
(These lines date back to when everything was in Base and FFTW was the only FFT implementation.)
In line 28, whoever originally wrote this expressly went out of their way to avoid using
y = similar(x)
. I can't seem to find any discussion as to why this was done except for the vague comment, but I'm currently trying to interface with AbstractFFTs and this would be a huge minus for me.Currently, I'm respecting whatever type the user inputs. While just plugging in AbstractFFTs would likely work just fine, I think this behavior could be undesirable. For example, right now, using
StaticVector
as both input and output accelerates the algorithms tremendously, which is particularly consequential when performing many very small FFTs. I asked @ararslan about this a few weeks ago, and got the response that this was ported over from when AbstractFFTs was in Base. Is it still necessary to do this?The text was updated successfully, but these errors were encountered: