[Python-ideas] real numbers with SI scale factors
Ken Kundert
python-ideas at shalmirane.com
Mon Aug 29 05:08:18 EDT 2016
> > These do not seem like good reasons for not doing this.
>
> Not worded the way you have them, no, because you've aimed for an
> extremely emotional argument instead of answering concrete questions
> like "where's the code that this would improve". Find some real-world
> code that would truly benefit from this. Show us how it's better.
Sorry, I am trying very hard not to let my emotions show through, and instead
provide answers, examples, and comments that are well reasoned and well
supported. I do find it frustrating that I appear to be the only one involved in
the conversation that has a strong background in numerical computation, meaning
that I have to carry one side of the argument without any support. It is
especially frustrating when that background is used as a reason to discount my
position. Let me try to make the case in an unemotional way.
It is hard to justify the need for SI scale factors being built into the
language with an example because it is relatively simple to do the conversion.
For example ...
With built-in support for SI scale factors:
h_line = 1.4204GHz
print('hline = {:r}Hz'.format(h_line))
...
In Python today:
from engfmt import Quantity
h_line = Quantity('1.4204GHz')
print('hline = {:q}'.format(h_line))
h_line = float(h_line)
...
Not really much harder to use the library. This is very similar to the situation
with octal numbers ...
With built-in support for octal numbers:
S_IFREG = 0o100000 # regular file
With out built-in support for octal numbers:
S_IFREG = int('100000', base=8) # regular file
So just giving a simple example is not enough to see the importance of native
support. The problem with using a library is that you always have to convert
from SI scale factors as the number is input and then converting back as the
number is output. So you can spend a fair amount of effort converting too and
from representations that support SI scale factors. Not a big deal if there is
only a few, but can be burdensome if there is a large number. But the real
benefit to building it in a native capability is that it puts pressure on the
rest of the ecosystem to also adopt the new way of representing real numbers.
For example, now the interchange packages and formats (Pickle, YaML, etc.) need
to come up with a way of passing the information without losing its essential
character. This in turn puts pressure on other languages to follow suit. It
would also put pressure on documenting and formatting packages, such as Sphinx,
Jinja, and matplotlib, to adapt. Now it becomes easier to generate clean
documentation. Also the interactive environments, such as ipython, need to
adapt. The more this occurs, the better life gets for scientists and engineers.
> Something that I don't think you've acknowledged is that the SI
> scaling markers are *prefixes to units*, not *suffixes to numbers*.
> That is to say, you don't have "132G" of a thing called a "pascal",
> you have "132" of a thing called a "gigapascal". Outside of a
> unit-based system, SI prefixes don't really have meaning. I don't
> remember ever, in a scientific context, seeing a coefficient of
> friction listed as "30 milli-something"; it's always "0.03". So if
> unitless values are simply numbers, and Python's ints and floats are
> unitless, they won't see much benefit from prefixes-on-nothing.
Yeah, this is why I suggested that we support the ability for users to specify
units with the numbers, but it is not a hard and fast rule. Once you add support
for SI scale factors, people find them so convenient that they tend to use them
whether they are units or not. For example, it is common for circuit designers
to specify the gain of an amplifier using SI scale factors even though gain is
often unitless. For example, gain=50k. Also, electrical engineers will often
drop the units when they are obvious, especially if they are long. For example,
it is common to see a resistance specified as 100k. When values are given in
a table and all the values in a column have the same units, it is common to give
numbers with scale factors by without units to save space.
-Ken
More information about the Python-ideas
mailing list