Skip to content
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

Open
martinholters opened this issue Aug 18, 2020 · 6 comments
Open

size, length, ndims for Plan inconsistent with Base usage #42

martinholters opened this issue Aug 18, 2020 · 6 comments

Comments

@martinholters
Copy link
Contributor

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, using size for this seems wrong. It should give the dimensions of the Plan itself, whatever that might be. As noted in JuliaMath/FFTW.jl#159, a Plan for 1d input of length n could be considered equivalent to a matrix with size (n, n), but size would just return n.

So we might consider renaming size as used here, and maybe ndims along with it if deemed necessary to have it, noting the trivial definition length(size(p)). I don't see how length 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 make Plans iterable (and maybe even indexable), where I don't see much benefit.

@dlfivefifty
Copy link
Member

dlfivefifty commented Aug 18, 2020

I'm skeptical about defining size, length, ndims in a way (more) consistent with Base, unless we make Plans iterable (and maybe even indexable), where I don't see much benefit.

I would argue there's a benefit in making it behave like the DFT matrix: that is, implement getindex, and support Matrix(plan_fft(...)), etc., for creating the DFT matrix.

The catch is one would have to make sense of 2D FFTs, probably as an Array{T,4}.

@stevengj
Copy link
Member

I would argue there's a benefit in making it behave like the DFT matrix:

What would it do for a multidimensional DFT plan?

@dlfivefifty
Copy link
Member

behave like AbstractArray{T,N} for N>2. Though this only makes sense if one makes sense of tensor arithmetic....

@stevengj
Copy link
Member

stevengj commented Aug 18, 2020

Though this only makes sense if one makes sense of tensor arithmetic....

Yes, this is what makes me worry that such an interpretation of size etcetera will have limited utility, since * in Julia does not generally have this meaning… whereas with the current meaning it is clear to me what it is good for.

@dlfivefifty
Copy link
Member

I was imagining that tensor * could in theory be implemented by a non-StdLib package. I have the sense that one could make sense of an Array{T,3} as a linear map from from matrices to vectors and an Array{T,4} as a map from matrices to matrices, but I suppose that it may not be so trivially defined (e.g. Array{T,3} also a map from vectors to matrices?). So I suppose renaming size is probably the best solution.

Anyone know of a good a reference/blog post for the difficulty in defining tensor *?

@grahamas
Copy link

If this ends up being addressed, it would be nice to be consistent with https://github.com/JuliaArrays/ArrayInterface.jl, e.g. implementing axes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants