[Python-ideas] real numbers with SI scale factors

[Alex Rudy]

> On Aug 29, 2016, at 06:08, Erik Bray <erik.m.bray at gmail.com> wrote:
> 
> On Mon, Aug 29, 2016 at 3:05 PM, Erik Bray <erik.m.bray at gmail.com <mailto:erik.m.bray at gmail.com>> wrote:
>> On Mon, Aug 29, 2016 at 9:07 AM, Ken Kundert
>> <python-ideas at shalmirane.com> wrote:
>>> On Mon, Aug 29, 2016 at 01:45:20PM +1000, Steven D'Aprano wrote:
>>>> On Sun, Aug 28, 2016 at 08:26:38PM -0700, Brendan Barnwell wrote:
>>>>> On 2016-08-28 18:44, Ken Kundert wrote:
>>>>>> When working with a general purpose programming language, the above numbers
>>>>>> become:
>>>>>> 
>>>>>>    780kpc -> 7.8e+05
>>>> [...]
>>>> 
>>>> For the record, I don't know what kpc might mean. "kilo pico speed of
>>>> light"? So I looked it up using units, and it is kilo-parsecs. That
>>>> demonstrates that unless your audience is intimately familiar with the
>>>> domain you are working with, adding units (especially units that aren't
>>>> actually used for anything) adds confusion.
>>>> 
>>>> Python is not a specialist application targetted at a single domain. It
>>>> is a general purpose programming language where you can expect a lot of
>>>> cross-domain people (e.g. a system administrator asked to hack on a
>>>> script in a domain they know nothing about).
>>> 
>>> I talked to astrophysicist about your comments, and what she said was:
>>> 1. She would love it if Python had built in support for real numbers with SI
>>>   scale factors
>>> 2. I told her about my library for reading and writing numbers with SI scale
>>>   factors, and she was much less enthusiastic because using it would require
>>>   convincing the rest of the group, which would be too much effort.
>>> 3. She was amused by the "kilo pico speed of light" comment, but she was adamant
>>>   that the fact that you, or some system administrator, does not understand
>>>   what kpc means has absolutely no affect on her desired to use SI scale
>>>   factors. Her comment: I did not write it for him.
>>> 4. She pointed out that the software she writes and uses is intended either for
>>>   herself of other astrophysicists. No system administrators involved.
>> 
>> 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.
> 
> I'll also add that syntactic support for units has rarely been an
> issue in Astropy.  The existing algebraic rules for units work fine
> with Python's existing order of operations.  It can be *nice* to be
> able to write "1m" instead of "1 * m" but ultimately it doesn't add
> much for clarity (and if really desired could be handled with a
> preparser--something I've considered adding for Astropy sources (via
> codecs).

I just want to add, as an astrophysicist who uses astropy.units: the astropy solution is pretty great, and I don’t mind the library overhead. I’d much rather have astropy.units, which does dimensional analysis, as well as handling SI prefixes for 2 reasons:
1. I don’t normally see or use SI prefixes without units, so bare SI prefixes are fairly worthless to me as a scientist. IF the units are going to be there, I’d much rather have a library that does a good job at dimensional analysis, and has taken my domain-specific concerns into account, for reasons fairly well covered in this thread.
2. I don’t find it cumbersome at all to use something like astropy.units which provides both the prefix and units for my code on input and output. The added syntactic weight of a single import, plus multiplication, is really not that big a burden, and makes it both clear what I am trying to write, and easy for the library to maintain this meaning when I use the variable later. e.g.
from astropy.units import *
distance = 10 * km

If that multiplication symbol is really too much to handle, then I’d rather see python support implicit multiplication as suggested above (i.e. “10 km” is parsed as “10 * km") and domain-specific libraries can support SI prefixes and units.

~ Alex

> 
> Best,
> Erik
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org <mailto:Python-ideas at python.org>
> https://mail.python.org/mailman/listinfo/python-ideas <https://mail.python.org/mailman/listinfo/python-ideas>
> Code of Conduct: http://python.org/psf/codeofconduct/ <http://python.org/psf/codeofconduct/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160829/dc8732a1/attachment-0001.html>