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

collect, begin and end #21

Open
RainerHeintzmann opened this issue Mar 22, 2021 · 4 comments
Open

collect, begin and end #21

RainerHeintzmann opened this issue Mar 22, 2021 · 4 comments

Comments

@RainerHeintzmann
Copy link

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
Copy link
Member

timholy commented Aug 18, 2021

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
Copy link
Author

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
Copy link
Member

timholy commented Aug 19, 2021

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
Copy link
Author

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.

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

2 participants