collect, begin and end

[RainerHeintzmann]

Using FFTViews I wanted to collect the array and display it. To this aim I tried

x = ones((1,10)) .*(1:10)
v = FFTView(x) # does not show the shifted view
c = collect(v) # collects the original data, not the view
c =v[-5:4,-5:4] # collects the shifted data
c = v[begin:end,begin:end] # is using the 0 to size index?

Are these all intended behaviours? For OffsetArray, begin, end work according to the shifted indices, but apparently not for an FFTView. To collect the shifted view, I ended up using:

start = CartesianIndex(size(v).÷2)
stop = CartesianIndex(size(v).÷2 .+size(v))
c = v[start:stop]

but is there an easier way to achieve the same? Thanks for any thoughts on this, Rainer

[timholy]

There's a certain sense in which begin and end don't even exist: the key feature of this array type is that the indexes satisfy periodic boundary conditions. What sense were you hoping for, starting at the halfway point and wrapping around?

[RainerHeintzmann]

I guess, I would have expected v to be a view being indexed with -5 being the first index an 4 the last. If you collect it, you get the same result as fftshift. Yet, if you don't collect it just feels like an array where you can index with integer k positions.

[timholy]

It's not really an fftshift do-over, it's a genuinely-periodic array type. But all arrays do have to return axes, so this package has to pick something. I guess we could report the same axes as fftshift? Does that make sense for all uses? Is there any chance that could fix https://github.com/JuliaArrays/FFTViews.jl#caution-fftviews-are-not-composable?

[RainerHeintzmann]

I guess there could be users, which do expect a non-shifted view, but probably view, which would expect a view shifted by 1. I think such an axes could fix at least most composability problems.