Repository navigation
Bug: quantities (to vs. set_enabled_equivalencies) #2496
Description
Below, the same comparison is True is a I explicetly call .to(u/km/u.s, equivalencies=l2v) and False is I use the set_enabled_equivalencies context manager.
In [1]: import astropy.units as u
In [2]: l2v = u.doppler_optical(2800*u.angstrom)
In [3]: (3000 * u.Angstrom).to(u.km/u.s, equivalencies=l2v) > (500*u.km/u.s)
Out[3]: array(True, dtype=bool)
In [4]: with u.set_enabled_equivalencies(l2v):
print (3000 * u.Angstrom) > (500*u.km/u.s)
...:
False
Activity
[-]Bug: quantities (to vs. set_enabled equivalencies[/-][+]Bug: quantities (to vs. set_enabled_equivalencies)[/+]mhvk commentedon May 23, 2014
@hamogu - this is a tricky one, as build in quite deep in
Quantityis that for arithmetic the only thing one has to do to go from one unit to another is to multiply with a given scale -- and that we can get this scale by just transforming1 <old-unit>tonew-unit. Of course, for your equivalency, this is not true: some addition/subtraction has to be done as well. As a result,does the same as
and both yield
(which is smaller than zero, and hence the comparison returns
False).It's not immediately obvious to me how to change this, but I think we will have to let
quantity_helpersreturn transformation functions rather than scales. I'll think more about this, but in the meantime: cc @mdboom, @astrofrog.mhvk commentedon Sep 24, 2014
Came back to this bug again due to the movement of the milestone. Do think this is a tricky one and still do not see any solution other than changing
quantity_helpersuch that rather than returning scales, it returns transformation functions. As I've been working withQuantityquite a bit recently, I can try to implement this, but I would appreciate feedback on whether this is a good idea in the first place... @mdboom, @astrofrog?embray commentedon Sep 24, 2014
I would also definitely like to see a solution to this. The use case you suggested, using
set_enabled_equivalencies, is too beautiful to ignore (and rather ugly that it doesn't work). If no one else has any ideas I'll poke at this sometime when I have time (which sadly is not right now).embray commentedon Sep 24, 2014
(Though I'll add, depending on what you do inside that
withblock this could also be potentially very dangerous, though I guess the idea is to...not call anything inside thewithblock that you don't know what it's doing :)Test that equivalencies now properly work within ufuncs [closes astro…
Test that equivalencies now properly work within ufuncs [closes astro…
Test that equivalencies now properly work within ufuncs [closes astro…
mhvk commentedon Mar 12, 2015
Finally time to solve this issue -- see #3586
Test that equivalencies now properly work within ufuncs [closes astro…
Merge pull request #3586 from mhvk/quantity-scale-to-scaler
Test that equivalencies now properly work within ufuncs [closes astro…
Merge pull request #3586 from mhvk/quantity-scale-to-scaler