AbstractFFTs.jl icon indicating copy to clipboard operation
AbstractFFTs.jl copied to clipboard

`size`, `length`, `ndims` for `Plan` inconsistent with Base usage

Open martinholters opened this issue 5 years ago • 6 comments
trafficstars

Ref. https://github.com/JuliaMath/FFTW.jl/issues/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 https://github.com/JuliaMath/FFTW.jl/issues/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.

martinholters avatar Aug 18 '20 08:08 martinholters

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}.

dlfivefifty avatar Aug 18 '20 09:08 dlfivefifty

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

What would it do for a multidimensional DFT plan?

stevengj avatar Aug 18 '20 12:08 stevengj

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

dlfivefifty avatar Aug 18 '20 13:08 dlfivefifty

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.

stevengj avatar Aug 18 '20 15:08 stevengj

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 *?

dlfivefifty avatar Aug 18 '20 15:08 dlfivefifty

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

grahamas avatar Mar 23 '21 20:03 grahamas