[Python-ideas] real numbers with SI scale factors

[Ken Kundert]

> 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.

Well the comment about bugs in speculation that does not fit with the extensive 
experience in the electrical engineering community. But other than that, these 
arguments could be used against supporting binary, octal, and hexadecimal 
notation. Are you saying building those into the language was a mistake?

On Sun, Aug 28, 2016 at 07:32:35PM -0700, David Mertz wrote:
> -1 on Python ever having any syntactic support for SI scale factors.
> 
> 
> 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).

Yes, without an convenient way of specifying real numbers, the computation 
communities have to resort to things like this. And they can work for a while, 
but over type the scale of things often change, and good choice of scale can 
turn bad after a few years. For example, when I first started in electrical 
engineering, the typical size of capacitors was in the micro Farad range, and 
software would just assume that if you gave a capacitance it was in uF. But 
then, with the advancement of technology the capacitors got smaller. They went 
from uF to nF to pF and now a growing fraction of capacitors are specified in 
the fF range. The fact that SPICE allowed values to be specified with SI scale 
factors, meant that it continued to be easy to use over the years, whereas the 
programs that hard coded the scale of its numbers because increasing difficult 
to use and then eventually became simply absurd.

Even your example is a good argument for specifying numbers is SI scale factors.  
If I am using one of your molecular simulators, I don't want to specify the 
simulation time range as being from 1 to 1_000_000_000_000 fs. That is 
ridiculous. There are 12 orders of magnitude between the minimum resolvable time 
and the maximum. There are only two practical ways of representing values over 
such a wide range: using SI scale factors and using exponential notation. And we 
can tell which is preferred. You said femptoseconds, you did not say 1e-15 
seconds. Even you prefer SI scale factors.

-Ken



> 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/
> >