-
Notifications
You must be signed in to change notification settings - Fork 321
Slice with negative step inconsistent with python result #312
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
Comments
Interesting. This was definitely a surprise to me: In [25]: x = np.arange(16.)
In [26]: x[:4:-1]
Out[26]: array([ 15., 14., 13., 12., 11., 10., 9., 8., 7., 6., 5.]) |
I just noticed this. In #377, I copied the existing behavior. Other than the Python and
Option 1 makes sense to me since I've used Python for a while, but it doesn't match the documentation for Option 2 matches the docs for I think option 3 is the best fit for What do you think? If you'd like to change the behavior, the 0.11 release would be a good time to do so. Either way, I can add more documentation to explain how negative steps are handled. |
Great to see the details! My default would be to not change the behaviour, so it would be best to have both the logical reason and a technical reason (like: fits this algorithm better or can be implemented with less conversion / checking loss etc). As a rebuttal, the last element in Python just seems to do one thing differently -- it swaps the ends of |
I don't have a strong preference, although I think options 2 and 3 fit Rust conventions a little better than option 1. Python's approach (option 1) to
Option 3's approach is "If Note that if we keep
Keeping the existing behavior fine with me. I don't see any technical reason to prefer one approach over another (other than the ability to add |
First of all, I understand that this crate is not meant to reproduce all feature in python, but since in the docs about Si python slice is used as comparison, so I believe this is worth to bring up.
Here is some test case with ndarray:
which return:
and in the corresponding python test case (in both python 2.7.6 and python 3.4.3):
which return:
It seems that, with negative step, the default begin is n - 1 and the default end is 0 for python. To be honest, I prefer the ndarray approach to kept the default consistance, but I believe this should either mention in the docs or changed.
The text was updated successfully, but these errors were encountered: