8000 Test for numpy issue 6133 by DanielSank · Pull Request #143 · labrad/pylabrad · GitHub
[go: up one dir, main page]
Skip to content

Test for numpy issue 6133 #143

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

Test for numpy issue 6133 #143

wants to merge 1 commit into from

Conversation

DanielSank
Copy link
Member

This PR adds a check to make sure we aren't hit by numpy issue 6133.

@DanielSank
Copy link
Member Author

Looks like Travis is hit by this bug. That probably means we need to change the numpy version it uses. @maffoo what's the deal here?

@jwenner
Copy link
Contributor
jwenner commented Jul 30, 2015

Is this numpy issue used in pylabrad? If so, do we want to add a note in the readme file along with a check when pylabrad is imported to warn users not to use Python 2.7.6/Numpy 1.9.2? Perhaps a check like in the pyle init file?

@DanielSank
Copy link
Member Author

@maffoo I'd be happy to see what's going on with Travis but I need access. Where is it?

@maffoo
Copy link
Contributor
maffoo commented Aug 1, 2015

@DanielSank, on the PR page by the failed check there should be a Details link that takes you to travis with the build results. It should all be public, but let me know if you can't see it. Just in case, the page for this most recent build failure is here.

@DanielSank
Copy link
Member Author

@maffoo yes, but my point is that it's failing because the bug we say on our machines yesterday is happening on Travis. This is probably a numpy bug, so perhaps we should consider going to an older (and lab standard) version. I can't do that myself...

@maffoo
Copy link
Contributor
maffoo commented Aug 1, 2015

just change .travis.yml in your branch and push. That file (and some scripts that it references) are what define the test. You can specify versions of numpy or other dependencies there. Right now it just grabs the latest for everything.

@DanielSank
Copy link
Member Author

Aha! Thanks.

@maffoo
Copy link
Contributor
maffoo commented Sep 11, 2015

@DanielSank, what's the status here? The docstring seems to indicate you wanted to investigate the numpy bug more.

@DanielSank
Copy link
Member Author

The status is I forgot about this. If you want to fix the travis go ahead. Sorry, I'm prepping for group meeting atm.

@ejeffrey
Copy link
Contributor

I tracked this down a bit further. The problem is that DimesionlessFloat has an array_priority set, but it can't handle math operations where "other" is a numpy array type since it just delegates to float which doesn't understand arrays. It returns NotImplemented (correctly), but numpy's array_priority machinery doesn't handle this case. numpy 1.9 converts numpy scalars to arrays before calling arithmetic operations, while numpy 1.8 does not.

I found an equivalent bug in numpy 1.8:

>>> a = U.DimensionlessFloat(3.0)
>>> b = 3.0
>>> c = np.arange(5)
>>> a < c
True
>>> b < c
array([False, False, False, False,  True], dtype=bool)

The latter result being correct.

@ejeffrey ejeffrey mentioned this pull request Oct 20, 2015
Merged
@ejeffrey
Copy link
811C Contributor

I folded this into a PR that fixes the bug.

@ejeffrey ejeffrey closed this Oct 20, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@DanielSank @jwenner @maffoo @ejeffrey
0