-
-
Notifications
You must be signed in to change notification settings - Fork 10.8k
gradient() no longer accepts scalar-like wrappers for dx #8292
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
Any thoughts of ways to improve this? |
Aside, I wonder if the generator needs to be in a list? |
List is definitely unnecessary. The ideal solution is probably to make |
Hmm, making gradient work correctly here could get tricky, especially with unevenly spaced samples as proposed in #8446. For scalars, it is suggested that custom scalar types inherit from |
It's just a thin wrapper around a Python integer: In [1]: import pint
In [2]: import numpy as np
In [3]: ureg = pint.UnitRegistry()
In [4]: 1 * ureg('m')
Out[4]: <Quantity(1, 'meter')>
In [5]: type((1 * ureg('m')).magnitude)
Out[5]: int |
Seems like |
It'd be more like s = 1 * ureg('m')
isinstance(s, int) But regardless, that last check returns |
Not sure, but |
The former example (numpy v.1.10): |
bump...I'm using another package pynbody which implements |
@ibackus: This looks like an easy fix to me, making the change I suggest in the comment above. Do you want to have a crack at implementing it? |
@eric-wieser: For now I'll have to pass...I've not contributed to numpy before and don't really have the time to getting things set up so that I can do that properly. all that is required is changing |
@eric-wieser, I would fix this but I do not grasp your solution fully. I see that |
Assuming you mean |
Looking into it I found this might already been resolved by #8446? |
This is with 1.12.0b1.
gradient()
no longer works with scalar values from a package called pint. With 1.11, this works:With the beta you get:
It looks like the new behavior was introduced by #7618. It seems like
isscalar
failed before forpint
-based scalar values; the problem is the check being added to gradient. Thepint
scalars behave just like scalars for all purposes, so IMO there should be no problem passing them in.It should be noted, though, that
gradient
itself has other problems working with the array-like objects frompint
, and required wrapping gradient to use it anyway. This breaking isn't the end of the world--I just thought you guys should be aware of the impacts.The text was updated successfully, but these errors were encountered: