-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
DataArray .rolling() unclear behaviour when center=False #8958
Comments
Thanks for opening your first issue here at xarray! Be sure to follow the issue template! |
I think you're being surprised by the fact that |
Indeed, I saw it and get rid of it at one point with dropna(). I guess it is worth mentioning / expliciting a little bit in the docs. For the plots, I remedy with .isel(<3rd_dim>=-1) instead of just .isel(<3rd_dim>=0) as stated before: from matplotlib import pyplot as plt
t_before_s = 0.5
t_after_s = 0.5
time_slice = slice(xr_test_data.epoch_onsets[0] + pd.Timedelta(-t_before_s,'s'), xr_test_data.epoch_onsets[0] + pd.Timedelta(t_after_s,'s'))
plt.figure()
xr_test_data['raw_eeg'].sel(time=time_slice, channel='O1').plot.line(x='time', hue='channel')
plt.figure()
xr_test_data['resampled_eeg'].sel(resampled_time=time_slice, channel='O1').plot.line(x='resampled_time', hue='channel')
plt.figure()
xr_test_data['full_code'].sel(resampled_time=time_slice).plot.line(x='resampled_time')
plt.figure()
xr_test_data['windowed_eeg'].sel(window_time=time_slice, channel='O1').isel(window_tvec=-1).plot.line() I do not feel confident enough to explicit the behaviour of construct() and specify examples by myself for the docs, but will gladly assist and contribute if someone feels like it. |
What is your issue?
Hi,
I am using the rolling().construct() method which I found very convenient and efficient.
I had timeseries with 2 dimensions: time and channel. I used the construct to produce small overlapping windows of samples on all channels:
However, after not obtaining the result I expected, I found out that the new coord window_time, was corresponding to the original time coords at the end/right of the window, and not as the first time coord of the window as I expected.
There is no argument to specify this apparently, as in its current state, it allows only for taking the "center coord" or the "right coord" (if center=False).
I expect that the way I wanted it is not so uncommon, so implementing that possibility would be great. But more urgently, I would find it extremely useful and avoiding puzzling debbugging if this behaviour was clearly explained in the API reference.
But maybe I am missing something here?
Thanks for your great work !
The text was updated successfully, but these errors were encountered: