Thanks to visit codestin.com
Credit goes to github.com

Skip to content

BUG: revert trim_zeros changes from gh-16911 #17171

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

Merged
merged 1 commit into from
Aug 27, 2020
Merged

Conversation

mattip
Copy link
Member

@mattip mattip commented Aug 27, 2020

xref PRs gh-16911, gh-17058, gh-17131 and issue gh-16783.

While the effort to speed up and rethink trim_zeros is appreciated, in this case I think we should unfortunately revert these changes. I have added a test that lists remain unchanged.

Comment on lines +1228 to +1230
def test_list_to_list(self):
res = trim_zeros(self.a.tolist())
assert isinstance(res, list)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume this test does not pass on master?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does as self.a is just a normal 1D array of integers.

However, there is currently no test which checks the return type so I feel this is a nice addition.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to work out whether this is a case of @mattip generally wishing to reseal the can of worms, or if there was a specific worm that we knew was an incompatibility.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mainly seal the can of worms. I am a bit dubious if the new implementation actually achieves what it promises, personally. (Depending on the use-case, you may be stripping only one value from a very large array, making the old code much faster. OTOH, maybe that use-case doesn't actually matter since in almost all cases the work done on the result will be much slower anyway.)

If you are fairly certain the updated version seals it well, I think we can go with that as well. I had never looked very carefully, but it seemed a bit hard to be sure previously, and trim_zeros seemed a bit niche to worry about much...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PR reverts the code to its state before the first PR gh-16911. I added the passing test to cover a use case that previously was not tested.

@charris
Copy link
Member

charris commented Aug 27, 2020

@eric-wieser We also want it resolved quickly so that the weekly wheels get built for testing.

@eric-wieser
Copy link
Member

I've no opposition to reverting it, especially if there's consensus between @charris, @mattip, and @seberg. I don't think the value provided by the fast version is that great anyway.

@seberg
Copy link
Member

seberg commented Aug 27, 2020

Then lets put this in for now/ At least for the wheels... Sorry if you want to still pursue the initial improvement, which will be a bit more difficult with this reverting. Thanks for all the effort @BvB93 !

@seberg seberg merged commit e4e0ab8 into numpy:master Aug 27, 2020
@BvB93
Copy link
Member

BvB93 commented Aug 27, 2020

Ah well, it was worth a shot.

@mattip mattip deleted the revert-16911 branch January 25, 2022 08:23
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

Successfully merging this pull request may close these issues.

5 participants