On Tue, Aug 30, 2016 at 5:48 AM, Ken Kundert <python-id...@shalmirane.com> wrote: > 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?
Hi Ken, I see what you're getting at, and that's a good idea. There's also nothing in the current implementation preventing it, and I think I'll even suggest this to Astropy (with proper attribution)! I think there are reasons not to always do this, but it's a nice option to have. Point being nothing about this particular feature requires special support from the language, unless I'm missing something obvious. And given that Astropy (or any other units library) is third-party chances are a feature like this will land in place a lot faster than it has any chance of showing up in Python :) Best, Erik > 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/
