[Python-ideas] real numbers with SI scale factors

[Erik Bray]

On Mon, Aug 29, 2016 at 3:05 PM, Erik Bray <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).

Best,
Erik