[Python-ideas] real numbers with SI scale factors

[Chris Angelico]

On Mon, Aug 29, 2016 at 1:29 PM, Ken Kundert
<python-ideas at shalmirane.com> wrote:
> Because by focusing on the implementation details, we miss the big picture.  We
> have already done that, and we ended up going down countless ratholes.

They're important ratholes though. Without digging into those
questions, all you have is an emotive argument of "but we NEEEEEEED to
support SI prefixes as integer suffixes!".

>> > Don't Python's users in the scientific and engineering communities deserve
>> > the same treatment?  These are, after all, core communities for Python.
>>
>> Yes. That's why we have things like the @ matrix multiplication
>> operator (because the numeric computational community asked for it),
>> and %-formatting for bytes strings (because the networking, mainly
>> HTTP serving, community asked for it). Python *does* have a history of
>> supporting things that are needed by specific sub-communities of
>> Python coders. But there first needs to be a demonstrable need. How
>> much are people currently struggling due to the need to transform
>> "gigapascal" into "e+9"? Can you show convoluted real-world code that
>> would be made dramatically cleaner by language support?
>
> Can you show code that would have been convoluted if Python had used a library
> rather than built-in support for hexadecimal numbers?

See my other email, with examples of bit flags. It's not too bad if
you only ever work with a single bit at a time, but bit masks combine
beautifully in binary, fairly cleanly in hex, and really badly in
decimal. Hex is a great trade-off between clean bit handling and
compact representation. (Octal is roughly the same trade-off, and in
days of yore was the one obvious choice, but hex has overtaken it.)

> So, in summary, you are suggesting that we tell the scientific and engineering
> communities that we refuse to provide native support for their preferred way of
> writing numbers because:
> 1. our way is better,

Is more general, yes. If all you have is SI prefixes, you're badly
scuppered. If all you have is exponential notation, you can do
everything.

> 2. their way is bad because some uneducated person might see the numbers and not
>    understand them,

Is, again, less general. It's a way of writing numbers that makes
sense only in a VERY narrow area.

> 3. we already have way of representing numbers that we came up with in the '60s
>    and we simply cannot do another,

False.

> 4. well we could do it, but we have decided that if you would only adapt to this
>    new way of doing things that we just came up with, then we would not have to
>    do any work, and that is better for us. Oh and this this new way of writing
>    numbers, it only works in the program itself. Your out of luck when it comes
>    to IO.

I'm not sure what you mean by "IO" here, but if you're writing a
program that accepts text strings and prints text strings, it's free
to do whatever it wants.

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

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.

ChrisA