Repository navigation
numpy.dot and numpy.cross won't preserve Quantity #1930
Description
I'm using astropy 0.3 under python 3.3 with numpy 1.8.0, and I found that np.dot won't preserve Quantityes as inputs:
>>> import numpy as np
>>> from astropy import units as u
>>> q = 1 * u.m; q
<Quantity 1 m>
>>> np.dot(q, q)
1
>>> np.sum(q * q)
<Quantity 1 m2>
the same happens with np.cross:
>>> r = [1, 0, 0] * u.m
>>> v = [0, 1, 0] * u.m / u.s
>>> np.cross(r, v)
array([0, 0, 1])
Activity
demorest commentedon Dec 28, 2013
I've recently noticed this problem as well. In case it helps, you can work around it by calling (in your example) q.dot(q) instead of np.dot(q,q). This usage does seem to preserve units in the result.
mhvk commentedon Dec 28, 2013
@Juanlu001 - thanks for the report! This is a problem with
numpynot providing a hook where we can tell it that its input is aQuantityrather than a regular numpy array. There are a few more places where this is an issue (e.g.,np.inner,np.outer,np.hstack; see #1274); some of these should be relatively easy to fix with numpy 1.9. If you find any other work-arounds, maybe add them to #1274 for now (I'll add @demorest's suggestion there for now, so there is a record).@astrofrog - this does seem a duplicate of #1274, so I think it can be closed.
astrojuanlu commentedon Dec 28, 2013
@mhvk It's true, I didn't see that report before. Thanks for the prompt response! I'm not that creative but if I find another work-around I will ping.
Just out of curiosity, why does numpy 1.9 make things easier? Which are the relevant changes?
mhvk commentedon Dec 28, 2013
numpy 1.9 introduces a
__numpy_ufunc__attribute [1] that makes overriding easier than the current system with__array_prepare__,__array_wrap__, and__array_finalize__(it includesnp.dot, though that is not strictly aufunc). I started a trial [2], but haven't really gotten around to seeing exactly what it solves and doesn't.[1] http://docs.scipy.org/doc/numpy-dev/reference/arrays.classes.html
[2] https://github.com/mhvk/astropy/compare/quantity-numpy-ufunc?expand=1
astrojuanlu commentedon Dec 28, 2013
Good to know, I was not aware of this. Let's hope it helps fixing the issue - another function that doesn't work that I use quite frequently is
numpy.linalg.norm.hamogu commentedon Dec 29, 2013
Just for the record:
scipy.integrate.odeintalso does not preserve a quantity.mhvk commentedon Dec 29, 2013
@hamogu -
scipyroutines may be harder to get right, but worth looking into...astrojuanlu commentedon Dec 29, 2013
Well, taking into account that f2py is black sorcery I think one's sanity would be seriously endangered :)
embray commentedon Dec 30, 2013
I feel like the fact that some of these routines don't work with quantities was a known issue at release time, but never got documented on the "Known Issues" page or anywhere else I can find. If it does go on "Known Issues" the Quantity docs should link to that section. Some of these will be fixable with monkey-patching a la #1274, but some of them may remain "known issues".
Added propagation code, removed twobody package
mhvk commentedon Jul 11, 2014
Closing this since this is part of a general problem that likely will need having our own versions of some numpy functions; see #2327.
astrojuanlu commentedon Aug 21, 2018
The original problem, which was that
np.dotandnp.crossdon't retain the units, still persists with latest NumPy and Astropy. I got a bit lost on how Astropy wanted to workaround the issue or NumPy to provide a better API, could you please give a brief explanation?pllim commentedon Aug 21, 2018
@Juanlu001 , please see https://astropy.readthedocs.io/en/latest/known_issues.html#quantities-lose-their-units-with-some-operations
astrojuanlu commentedon Aug 21, 2018
Thanks @pllim, I lost sight of that part!