On Mon, Aug 29, 2016 at 11:44 AM, Ken Kundert
<python-id...@shalmirane.com> wrote:
> 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.
>
And easier to compare. The SI prefixes are almost consistent in using
uppercase for larger units and lowercase for smaller, but not quite;
and there's no particular pattern in which letter is larger. For
someone who isn't extremely familiar with them, that makes them
completely unordered - which is larger, peta or exa? Which is smaller,
nano or pico? Plus, there's a limit to how far you can go with these
kinds of numbers, currently yotta at e+24. Exponential notation scales
to infinity (to 1e308 in IEEE 64-bit binary floats, but plenty further
in decimal.Decimal - I believe its limit is about 1e+(1e6), and REXX
on OS/2 had a limit of 1e+(1e10) for its arithmetic), remaining
equally readable at all scales.
So we can't get rid of exponential notation, no matter what happens.
Mathematics cannot usefully handle a system in which we have to
represent large exponents with ridiculous compound scale factors:
sys.float_info.max = 179.76931348623157*Y*Y*Y*Y*Y*Y*Y*Y*Y*Y*Y*Y*E
(It's even worse if the Exa collision means you stop at Peta.
179.76931348623157*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*P*M, anyone?)
Which means that these tags are a duplicate way of representing a
specific set of exponents.
> 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?
Except that those are exactly the important questions to be answered.
How *could* it be done? With the units stripped off, your examples
become:
780k == 7.8e+05 == 780*k
108M == 1.08e+08 == 108*M
600T == 6e+14 == 600*T
3.2G == 3.2e+09 == 3.2*G
53p == 5.3e-11 == 53*p
8G == 8e+09 == 8*G
Without any support whatsoever, you can already use the third column
notation, simply by creating this module:
# si.py
k, M, G, T, P, E, Z, Y = 1e3, 1e6, 1e9, 1e12, 1e15, 1e18, 1e21, 1e24
m, μ, n, p, f, a, z, y = 1e-3, 1e-6, 1e-9, 1e-12, 1e-15, 1e-18, 1e-21, 1e-24
u = μ
K = k
And using it as "from si import *" at the top of your code. Do we see
a lot of code in the wild doing this? "[H]ow it will be used after
it's done" is exactly the question that this would answer.
> 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?
ChrisA
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
