Erik,
One aspect of astropy.units that differs significantly from what I am
proposing is that with astropy.units a user would explicitly specify the scale
factor along with the units, and that scale factor would not change even if the
value became very large or very small. For example:
>>> from astropy import units as u
>>> d_andromeda = 7.8e5 * u.parsec
>>> print(d_andromeda)
780000.0 pc
>>> d_sun = 93e6*u.imperial.mile
>>> print(d_sun.to(u.parsec))
4.850441695494146e-06 pc
>>> print(d_andromeda.to(u.kpc))
780.0 kpc
>>> print(d_sun.to(u.kpc))
4.850441695494146e-09 kpc
I can see where this can be helpful at times, but it kind of goes against the
spirit of SI scale factors, were you are generally expected to 'normalize' the
scale factor (use the scale factor that results in the digits presented before
the decimal point falling between 1 and 999). So I would expected
d_andromeda = 780 kpc
d_sun = 4.8504 upc
Is the normalization available astropy.units and I just did not find it?
Is there some reason not to provide the normalization?
It seems to me that pre-specifying the scale factor might be preferred if one
is
generating data for a table and all the magnitude of the values are known in
advance to within 2-3 orders of magnitude.
It also seems to me that if these assumptions were not true, then normalizing
the scale factors would generally be preferred.
Do you believe that?
-Ken
On Mon, Aug 29, 2016 at 03:05:50PM +0200, Erik Bray wrote:
> Astropy also has a very powerful units package--originally derived
> from pyunit I think but long since diverged and grown:
>
> http://docs.astropy.org/en/stable/units/index.html
>
> It was originally developed especially for astronomy/astrophysics use
> and has some pre-defined units that many other packages don't have, as
> well as support for logarithmic units like decibel and optional (and
> customizeable) unit equivalences (e.g. frequency/wavelength or
> flux/power).
>
> That said, its power extends beyond astronomy and I heard through last
> week's EuroScipy that even some biology people have been using it.
> There's been some (informal) talk about splitting it out from Astropy
> into a stand-alone package. This is tricky since almost everything in
> Astropy has been built around it (dimensional calculations are always
> used where possible), but not impossible.
>
> One of the other big advantages of astropy.units is the Quantity class
> representing scale+dimension values. This is deeply integrated into
> Numpy so that units can be attached to Numpy arrays, and all Numpy
> ufuncs can operate on them in a dimensionally meaningful way. The
> needs for this have driven a number of recent features in Numpy. This
> is work that, unfortunately, could never be integrated into the Python
> stdlib.
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
