Repository navigation
units: warning from numpy operation on Quantity arithmetic #3240
Description
The following gives a warning:
from astropy import units as u
import numpy as np
a = 15 * u.kpc
b = 27 * u.pc
print np.arcsin((b/a))
but doing this does not:
print np.arcsin((b/a).decompose())
The warning is:
RuntimeWarning: invalid value encountered in arcsin
print np.arcsin((b/a))
Activity
decompose height/distance calculation to avoid weird Quantity behavio…
anuraghota commentedon Dec 19, 2014
Because we already set the parameters,
will not give warning. (Note the extra brackets removed)
instead of -
Suppose we write
This will work good!
mhvk commentedon Dec 19, 2014
Careful -- the warning only appears once... it has nothing to do with double parentheses.
Bizarre.
mhvk commentedon Dec 19, 2014
OK, I think I got it: the problem is that
astropycallsnp.arcsintwice, once with just the value of the quantity, and another time with the value properly scaled. So, sinceb/a=1.8 pc / kpc, it first callsnp.arcsin(1.8)(which raises the warning and returnsnan), then discards this result, and then recalculatesnp.arcsin(0.0018).With current
numpy, this is actually unavoidable: we are allowed to prepare output arrays in__array_prepare__and do corrections to the output in__array_wrap__but we cannot take into account the units of the inputs before the actual calculation (so, we recalculate in__array_wrap__if needed). This will only change withnumpy 1.10and its__numpy_ufunc__method (see #2583).But this issue suggests we should silence
numpywarnings for the initial calculation. Not completely sure if this can easily be done safely (i.e., ensuring that a mistimed ctrl-C doesn't mess up things). @mdboom, @embray?embray commentedon Dec 19, 2014
Yeah, that's tricky--we could silence the warning in
__array_prepare__and restore it later, but a lot could go wrong there. That said, the worst that can happen is the warning would be permanently silenced for the rest of the user's session. Other things could be done to try to avoid this like registering a signal handler and such but it's all probably more effort than it's worth. I'd lean toward just documenting this as a known issue for Numpy < 1.10.adrn commentedon Jul 3, 2016
I still see this warning in the current Astropy master with Numpy 1.11.1 -- from what I understand in reading #2583 , this is because the
__numpy_ufunc__stuff got pushed to Numpy 1.12?