-
Notifications
You must be signed in to change notification settings - Fork 34
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
size
, length
, ndims
for Plan
inconsistent with Base usage
#42
Comments
I would argue there's a benefit in making it behave like the DFT matrix: that is, implement The catch is one would have to make sense of 2D FFTs, probably as an |
What would it do for a multidimensional DFT plan? |
behave like |
Yes, this is what makes me worry that such an interpretation of |
I was imagining that tensor Anyone know of a good a reference/blog post for the difficulty in defining tensor |
If this ends up being addressed, it would be nice to be consistent with https://github.com/JuliaArrays/ArrayInterface.jl, e.g. implementing |
Ref. JuliaMath/FFTW.jl#159
While it is certainly useful to be able to query a
Plan
for the size of the input data it expects, usingsize
for this seems wrong. It should give the dimensions of thePlan
itself, whatever that might be. As noted in JuliaMath/FFTW.jl#159, aPlan
for 1d input of lengthn
could be considered equivalent to a matrix with size(n, n)
, butsize
would just returnn
.So we might consider renaming
size
as used here, and maybendims
along with it if deemed necessary to have it, noting the trivial definitionlength(size(p))
. I don't see howlength
is useful, so that could maybe just be deleted.I'm skeptical about defining
size
,length
,ndims
in a way (more) consistent with Base, unless we makePlan
s iterable (and maybe even indexable), where I don't see much benefit.The text was updated successfully, but these errors were encountered: