[Python-ideas] real numbers with SI scale factors

[David Mertz]

-1 on Python ever having any syntactic support for SI scale factors.

It makes the language needlessly complicated, has no benefit I've discerned
(vs using libraries), and is a magnet for a large class of bugs.

Btw, the argument below feels dishonest in another respect. Within a domain
there is a general size scale of quantities of interest. I worked in a
molecular dynamics lab for a number of years, and we would deal with
simulated timesteps of a few femtoseconds. A total simulation might run
into microseconds (or with our custom supercomputer, a millisecond).

There were lots of issues I don't begin to understand of exactly how many
femtoseconds might be possible to squeeze in a timesteps while retaining
good behavior. But the numbers of interest were in the range 0.5-5, and
anyone in the field knows that.

In contrast, cosmologists deal with intervals of petaseconds. Yeah, I know
it's not as simple as that, but just to get at the symmetry.

No one would write 2.5e-15 every time they were doing something with an MD
timestep. The scaling, if anywhere at all, would be defined once as a
general factor at the boundaries. The number of interest is simply, e.g.
2.5, not some large negative exponent on that.

In fact, at a certain point I proposed that we should deal with rounding
issues by calling the minimum domain specific time unit an attosecond, and
only use integers in using this unit. That wasn't what was adopted, but it
wasn't absurd. If we had done that, we simply deal with, say 1500 "inherent
units" in the program. The fact it related to a physical quantity is at
most something for documentation (this principle isn't different because we
used floats in this case).

On Aug 28, 2016 8:44 PM, "Ken Kundert" <python-ideas at shalmirane.com> wrote:

> Wow, things have suddenly turned very negative. I understand that this is
> very
> normal for these types of forums where it is easy to lose sight of the big
> picture. So let me try to refocus this discussion again.
>
>
> MOTIVATION
>
> The way the scientific and engineering communities predominately write real
> numbers is by using SI scale factors.  These numbers almost always
> represent
> physical quantities, so it is common to write the number with scale factor
> and
> units.  So for example, the distance to Andromeda is 780kpc, the pressure
> at the
> bottom of the Mariana Trench is 108MPa, the total power produced by a
> typical
> hurricane is 600TW, the number of base pairs in human DNA is 3.2Gb, and
> the Bohr
> radius is 53pm.  These numbers are the language of science and
> engineering, but
> in recent years they have also entered the realm of popular culture. For
> example, an article by Ars Technica that calculates that the value of the
> music
> that can fit on a classic iPod as over $8G (that is the total penalty that
> can
> be accessed if they were all stolen copyright works).
>
> http://arstechnica.com/tech-policy/2012/06/from-gigabytes-
> to-petadollars-copyright-math-begets-copyright-currency/
>
> In all of these examples the numbers are either very large or very small,
> and
> they employ the use of SI scale factors to make them easy to write and
> communicate.  This way of writing numbers is so well established that it
> was
> formally standardized as part of the International System of Units (the
> Système
> international d'unités) in 1960.
>
> The problem is that most general purpose programming languages do not
> support
> this way of writing numbers. Instead they force people to convert the
> numbers to
> and from exponential notation, which is rather inconvenient and hard to
> read,
> write, say, or hear (it is much easier to say or hear 53 picometers than
> 5.3e-11
> meters).
>
> When working with a general purpose programming language, the above numbers
> become:
>
>     780kpc -> 7.8e+05
>     108MPa -> 1.08e+08
>     600TW  -> 6e+14
>     3.2Gb  -> 3.2e+09
>     53pm   -> 5.3e-11
>     $8G    -> 8e+09
>
> Notice that the numbers become longer, harder to read, harder to type,
> harder to
> say, and harder to hear.
>
>
> NEXT STEP
>
> So the question is, should Python accommodate this widely used method of
> writing
> real numbers? Python already has many ways of writing numbers. For example,
> Python allows integers to be written in binary, octal, decimal and hex. Any
> number you can write in one form you can write in another, so the only real
> reason for providing all these ways is the convenience of the users. Don't
> Python's users in the scientific and engineering communities deserve the
> same
> treatment?  These are, after all, core communities for Python.
>
> Now, Python is a very flexible language, and it is certainly possible to
> add
> simple libraries to make it easy to read and write numbers with SI scale
> factors. I have written such a library (engfmt). But with such libraries
> this
> common form of writing numbers remains a second class citizen. The language
> itself does not understand SI scale factors, instead any time you want to
> input
> or output numbers in their natural form you must manually convert them
> yourself.
>
> Changing Python so that it understands SI scale factors on real numbers as
> first
> class citizens innately requires a change to the base language; it cannot
> be
> done solely through libraries.  The question before you is, should we do
> it?
>
> The same question confronted the developers of Python when it was decided
> to add
> binary, octal and hexadecimal number support to Python. You could have
> done it
> with libraries, but you didn't because binary, octal and hexadecimal
> numbers
> were too common and important to be left as second class citizens. Well,
> use of
> binary, octal and hexadecimal numbers is tiny compared to the use of real
> numbers with SI scale factors.
>
> Before we expend any more effort on this topic, let's put aside the
> question of
> how it should be done, or how it will be used after its done, and just
> focus on
> whether we do it at all. Should Python support real numbers specified with
> SI
> scale factors as first class citizens?
>
> What do you think?
>
> -Ken
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160828/321d36ce/attachment.html>