[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