Skip to content
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

How to best deal with copyto and pint? #553

Closed
NOhs opened this issue Sep 21, 2017 · 4 comments · Fixed by #905
Closed

How to best deal with copyto and pint? #553

NOhs opened this issue Sep 21, 2017 · 4 comments · Fixed by #905

Comments

@NOhs
Copy link

NOhs commented Sep 21, 2017

The copyto function complains that argument must be numpy.ndarray, not Quantity. I guess that this numpy function is one of the few that is not supported by pint currently. My current approach to work around this is:

# ...
tmp = destination.magnitude
np.copyto(tmp, source.magnitude)
destination= tmp * source.units

Are there any cleaner options to use copyto with units?

@hgrecco
Copy link
Owner

hgrecco commented Sep 22, 2017

Sadly there is no cleaner way to do this. It is not really that we have not supported, but that we cannot do it to the API that numpy exposes (See for example #232 )

@NOhs
Copy link
Author

NOhs commented Sep 22, 2017

Too bad. But it's not a deal breaker for me. Pint still works great in most situations!

@NOhs
Copy link
Author

NOhs commented Sep 22, 2017

You mentioned in #232 that you do not like the idea of subclassing ndarray, but you did not specify why? You also linked to a branch where you tested this out. What were the issues you encountered?

@hgrecco
Copy link
Owner

hgrecco commented Sep 27, 2017

At the time, we did not find a way to make it cleanly. We wanted:

  • NumPy Optional: Pint should work even without NumPy. This now might be possible as we have decoupled the registries providing different functionality.
  • Interoperable: going from a subclass object to a wrapped object should be transparent
  • Worth it: a large number of NumPy functions should become supported out of the box

I am open to look into this again if there is a good proposal

@bors bors bot closed this as completed in 43fbae2 Dec 11, 2019
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 a pull request may close this issue.

2 participants