[Python-ideas] real numbers with SI scale factors

[Chris Angelico]

On Mon, Aug 29, 2016 at 7:08 PM, Ken Kundert
<python-ideas at shalmirane.com> wrote:
>> > 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.

An "emotional argument" doesn't necessarily mean that your emotions
are governing everything - it's more that your line of reasoning is to
play on other people's emotions, rather than on concrete data. Your
primary argument has been "But think of all the scientific developers
- don't you care about them??", without actually giving us code to
work with. (In a recent post, you did at least give notes from a
conversation with a lady of hard science, but without any of her code,
we still can't evaluate the true benefit of unitless SI scaling.)

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

No no no; your background is not a reason to discount your position.
However, on its own, it's insufficient justification for your
position.

Suppose I come to python-ideas and say "Hey, the MUD community would
really benefit from a magic decoder that would use UTF-8 where
possible, ISO-8859-1 as fall-back, and Windows-1252 for characters not
in 8859-1". Apart from responding that 8859-1 is a complete subset of
1252, there's not really a lot that you could discuss about that
proposal, unless I were to show you some of my code. I can tell you
about the number of MUDs that I play, the number of MUD clients that
I've written, and some stats from my MUD server, and say "The MUD
community needs this support", but it's of little value compared to
actual code.

(For the record, a two-step decode of "UTF-8, fall back on 1252" is
exactly what I do... in half a dozen lines of code. So this does NOT
need to be implemented.)

That's why I keep asking you for code examples. Real-world code, taken
from important projects, that would be significantly improved by this
proposal. It has to be Python 3 compatible (unless you reckon that
this is the killer feature that will make people take the jump from
2.7), and it has to be enough of an improvement that its authors will
be willing to drop support for <3.6 (which might be a trivial concern,
eg if the author expects to be the only person running the code).

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

Maybe; or maybe you'd already be doing a lot of I/O work, and it's
actually quite trivial to slap in one little function call at one call
site, and magically apply it to everything you do. Without code, we
can't know. (I sound like a broken record here.)

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

Ewwww, I doubt it. That would either mean a whole lot of interchange
formats would need to have a whole new form of support. You didn't
mention JSON, but that's a lot more common than Pickle; and JSON is
unlikely to gain a feature like this unless ECMAScript does (because
JSON is supposed to be a strict subset of JavaScript's Object
Notation). Pickle - at least the one in Python - doesn't need any way
to store non-semantic information, so unless you intend for the scale
factor to be a fundamental part of the number, it won't need changes.
(People don't manually edit pickle files the way they edit JSON
files.) YAML might need to be enhanced. That's the only one I can
think of. And it's a big fat MIGHT.

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

Eww eww eww. You're now predicating your benefit on a huge number of
different groups gaining support for this. To what extent do they need
to take notice of the SI scales on numbers? Input-only? Output?
Optionally on output? How do you control this? Are SI-scaled numbers
somehow different from raw numbers, or are they equivalent forms (like
1.1e3 and 1100.0)? If they're equivalent forms, how do you decide how
to represent on output? Are all these questions to be answered
globally, across all systems, or is it okay for one group to decide
one thing and another another?

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

Gain of 50k, that makes reasonable sense. Resistance as 100k is a
shorthand for "100 kiloohms", and it's still fundamentally a
unit-bearing value.

All of this would be fine if you were building a front-end that was
designed *SOLELY* for electrical engineers. So maybe that's the best
way. Fork IDLE or iPython and build the very best electrical
engineering interactive Python; it doesn't matter, then, how crazy it
is for everyone else. You can mess with stuff on the way in and on the
way out, you can interpret numbers as unitless values despite being
written as "100kPa", and you can figure out what to do in all the edge
cases based on actual real-world usage. You'd have your own rules for
backward compatibility, rather than being bound by Python's release
model (18 months between feature improvements, and nothing gets
dropped without a VERY good reason), so you could chop and change as
you have need. The base language would still be Python, but it'd be so
optimized for electrical engineers that you'd never want to go back to
vanilla CPython 3.6.

Sound doable?

ChrisA