Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Some NumPy and SciPy operations drop units from arrays #59
A known issue with
>>> import numpy as np >>> from astropy import units >>> a = np.array([3.]) * units.m >>> b = np.array([4.]) * units.m >>> np.concatenate((a, b)) <Quantity [ 3., 4.] (Unit not initialised)>
There are some workarounds to some of these problems.
>>> np.isclose(500* u.km/u.s, 300 * u.km / u.s UnitsError: Can only apply 'add' function to dimensionless quantities when other argument is not a quantity (unless the latter is all zero/infinity/nan) >>> np.isclose(500* u.km/u.s, 300 * u.km / u.s, atol=1e-8 * u.mm / u.s) array([False], dtype=bool)
We cannot do anything from within PlasmaPy, but will need to wait for fixes within NumPy (e.g., new support for
A takeaway point: when writing functions that take Astropy Quantities as arguments, always include a unit test to test units.
>>> density_of_wombats = 18.7 * u.parsec**-3 >>> velocity_of_wombats = 0.04 * c >>> flux_of_wombats = density_of_wombats * velocity_of_wombats # second golden rule of astrophysics >>> assert flux_of_wombats.si.unit == units.m**-2 * units.s**-1
There is a quantity aware version of
Also a good way to make sure your functions return the correct units is to use the return annotations and
Once Astropy Quantities can work with
if isinstance(zeta, u.Quantity): if zeta.unit == u.dimensionless_unscaled: zeta = zeta.value
Would you mind if I added my 2 cents to the discussion?
I happen to be visiting @namurphy and we're discussing several piles of code I'd like to contribute to PlasmaPy. There are two concerns that have come up in our discussions. (1) How will data analysts and experimentalists use PlasmaPy? (2) How can we leverage already existing standards? I bring up (1) in #86. I'd like to focus on (2) here.
There is a lot of development in projects like pandas and xarray that handle a large number of proposed developments I've seen in the GitHub PlasmaPy e-mails I've received. Interpolation is just one example. Why re-implement an interpolation method in a new class that has to handle a whole bunch of things that others have already written into their subclasses. Pandas'
I bring up interpolation as it relates to units. There's a big discussion about how to implement units in PlasmaPy. Right now, we're busy creating a brand new Plasma object and developing it. At some point, we're going to redo a huge pile of development that already exists in Pandas or Xarray. Why not spend the time we'd be using to reinvent the wheel and just use it to implement units in a functional way for Pandas, Xarray, or even Numpy? That way, we can leverage the development they have done and not worry about writing our own test cases for things they have. After all, isn't PlasmaPy part of the growing set of open-source python projects?
Please always feel free, it's an open forum :)
My understanding is that none of those things is trivial. They may be slightly more efficient in the long term, but we also need to remember the short-term goal of providing useful funcitonality to users now.
I don't see that it's any less so if we decide existing tools don't serve our purposes and implement new ones that do.
To get back to the main topic of the issue, did we decide that using only Astropy >2.0 and Numpy >1.13 solves the problem, or are there still operations that don't output the untis correctly?