Open crusaderky opened 4 years ago
which raises the question of what kind of API pint should require from an arbitrary other library wrapping around pint.
I think this is indeed the point we need to address. With more libraries interacting with pint in a non-trivial way (i.e. libraries wrapping pint, not just using) we need to define a crystal clear interface. But we also need to revist the arguments of the methods that are exposed. Your case is a good example.
with only pint
and xarray
, I think
vb.copy(data=vb.data.to("kg", ctx))
is the best we can do right now. In the future, pint-xarray
should be able to simplify that to
vb.pint.to("kg", ctx)
I don't know anything about contexts, but I think for this to work we need q
in
ctx.add_transformation("[volume]", "[mass]", lambda ureg, q: q * density)
to somehow stay a xarray
object.
I have xarray.DataArray objects that wrap Quantity objects with more or less arbitrary dimensions, e.g. time or Monte Carlo shock ID. I find myself with vectorized physical specs - e.g. density - with other, also arbitrary, dimensions, e.g. shipment ID.
I would like to write something like this:
There are three problems:
which raises the question of what kind of API pint should require from an arbitrary other library wrapping around pint.
Ideas/suggestions? cc @jthielen @keewis @hgrecco @shoyer
Workarounds
Don't use pint.to and just multiply the two DataArrays. This is not so simple when writing a framework where the units are fully user-defined and more conversion steps can be chained together, e.g. convert m^3 to pounds
A very painful walkabout:
Note how in this case the context is throwaway, which slows things down because it can't rely on pint's caching.