You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Interesting, yes we assume that the index is numerical and starts from 0 because for most use cases it should. Other than a date-time index (which we don't formally support) it's a bit strange to slice rows and only call Design_Matrix methods on those rows; that was never intended usage. Was there something specific you were trying to accomplish by doing that?
I would recommend a .reset_index to avoid this issue, but I'm going leave this issue open and rename it in case we want to support more flexible use-cases in the future.
ejolly
changed the title
possible bug with design matrix add_poly
consider making Design_Matrix more flexible with custom index
May 4, 2020
yeah, we fixed it with .reset_index. I had never seen it before. If we don't do anything, it might be good to note this in the documentation that the indices should be the same length. I'm not sure how I feel about forcing a reset inside the add_poly() method (or any others), we could add a check to make sure indices match, not just length, and return a warning if not.
yea I don't love the idea of forcing a reset_index incase the user has a meaningful index they want to retain. Definitely think we should mention it in the docs tho or add a warning if the index doesn't start at 0.
issue appending (adds unwanted rows), using ver 0.3.19
code:
`# add motion covariates
curr_cov = covs.iloc[time1:time2, :]
cov = Design_Matrix(curr_cov, sampling_freq=samp_freq)
print(cov.shape)
output:
(45, 49) (53, 52)
The text was updated successfully, but these errors were encountered: