Re: [Python-ideas] SI scale factors in Python
Allow me to refine my answer to this question ... Yes, that is definitely problematic. I see two possible solutions. 1. Limit ourselves to the common scale factors: T, G, M, k, _, m, u, n, p, f, a 2. Or accept X in lieu of E. After all, the e is silent anyway. Thus, on input we accept ... 1Y -> 1e+24 1Z -> 1e+21 -> 1X -> 1e+18 <- only difference 1P -> 1e+15 1T -> 1e+12 1G -> 1e+09 1M -> 1e+06 1k -> 1e+03 1_ -> 1e+00 1m -> 1e-03 1u -> 1e-06 1n -> 1e-09 1p -> 1e-12 1f -> 1e-15 1a -> 1e-18 1z -> 1e-21 1y -> 1e-24 But on output we use ... 1Y -> 1e+24 optional 1Z -> 1e+21 optional -> 1E -> 1e+18 optional 1P -> 1e+15 optional 1T -> 1e+12 1G -> 1e+09 1M -> 1e+06 1k -> 1e+03 1_ -> 1e+00 1m -> 1e-03 1u -> 1e-06 1n -> 1e-09 1p -> 1e-12 1f -> 1e-15 1a -> 1e-18 1z -> 1e-21 optional 1y -> 1e-24 optional The optional scale factors are unfamiliar to most people, and if used might result in harder to read numbers. So I propose that '%r' only outputs the common scale factors, and %R outputs all the scale factors. Or we can use '#' in the format string to indicate the 'alternate' form should be used, in this case 'alternate' means that the extended set of scale factors should be used. -Ken
On 25 August 2016 at 09:54, Ken Kundert <python-ideas@shalmirane.com> wrote:
While these suffixes are suitable for a scientific context, in a computing context, 1k=1024, 1M=1024*1024 and 1G=1024*1024*1024 make just as much, if not more, sense (and yes, I'm aware of Gigabyte vs Gibibyte). If "1M" were a legal Python literal,. I would expect a lot of confusion over what it meant - to the extent that it would hurt readability badly. Paul
On 25 August 2016 at 06:06, Paul Moore <p.f.moore@gmail.com> wrote:
So, the idea of adding fixed sufixes to the core language I regard as awful - due to these and other considerations - But maybe, oen thign to think about is about "operatorless" multiplication - jsut puting two tokens side by side, which currently yieds a Syntax Error could call `__mul__` (or a new `__direct_mul__` method on the second operator. That would enable a lot of interesting things in already existing packages like SymPy - and would allow a "physics measurements" packages that would take care of the ideas on the starting of the thread. I certainly would be more confortable for mathematicians and other people using Python in interactive environments such as iPython notebooks. But other than having this as a multiplication, I am against the whole thing.
I have trouble imagining situations in which SI units would help readability over scientific notation. On the one hand reading it always involves mental conversion to the exponents, so this is just an extra step. E.g. this equality is evident at a glance: 1e3 * 1e6 * 1e-9 == 1 This one would take me a few seconds, and I'd need to run it twice in my head to make sure I wasn't doing it wrong: 1k * 1M * 1n == 1 The more complicated the expression, the bigger the cognitive advantage for numeric exponents. I think the OP is drawn astray by the utility of domain specific familiar dimensional units. 1MeV means something in a domain. So does 1ps. Or 1km. But really it's the units not the exponent that are helping us (plus knowing that our specific domain deals with dimensional quantities of a certain scale). But even past the ease of mental arithmetic, I don't see why one would use literals very often to start with. If they are constants, give them a better name! If they are variables, likewise. If it helps your domain, add the units to the *names*, e.g.: lightyear_m = 9.5e15 galaxy_radians = calculate_arc() dist_m = lighyear_m * galaxy_radians * arc_len That looks a lot clearer to me than sticking together raw numbers, however spelled. On Aug 25, 2016 2:56 AM, "Joao S. O. Bueno" <jsbueno@python.org.br> wrote:
On 25 August 2016 at 09:54, Ken Kundert <python-ideas@shalmirane.com> wrote:
While these suffixes are suitable for a scientific context, in a computing context, 1k=1024, 1M=1024*1024 and 1G=1024*1024*1024 make just as much, if not more, sense (and yes, I'm aware of Gigabyte vs Gibibyte). If "1M" were a legal Python literal,. I would expect a lot of confusion over what it meant - to the extent that it would hurt readability badly. Paul
On 25 August 2016 at 06:06, Paul Moore <p.f.moore@gmail.com> wrote:
So, the idea of adding fixed sufixes to the core language I regard as awful - due to these and other considerations - But maybe, oen thign to think about is about "operatorless" multiplication - jsut puting two tokens side by side, which currently yieds a Syntax Error could call `__mul__` (or a new `__direct_mul__` method on the second operator. That would enable a lot of interesting things in already existing packages like SymPy - and would allow a "physics measurements" packages that would take care of the ideas on the starting of the thread. I certainly would be more confortable for mathematicians and other people using Python in interactive environments such as iPython notebooks. But other than having this as a multiplication, I am against the whole thing.
I have trouble imagining situations in which SI units would help readability over scientific notation. On the one hand reading it always involves mental conversion to the exponents, so this is just an extra step. E.g. this equality is evident at a glance: 1e3 * 1e6 * 1e-9 == 1 This one would take me a few seconds, and I'd need to run it twice in my head to make sure I wasn't doing it wrong: 1k * 1M * 1n == 1 The more complicated the expression, the bigger the cognitive advantage for numeric exponents. I think the OP is drawn astray by the utility of domain specific familiar dimensional units. 1MeV means something in a domain. So does 1ps. Or 1km. But really it's the units not the exponent that are helping us (plus knowing that our specific domain deals with dimensional quantities of a certain scale). But even past the ease of mental arithmetic, I don't see why one would use literals very often to start with. If they are constants, give them a better name! If they are variables, likewise. If it helps your domain, add the units to the *names*, e.g.: lightyear_m = 9.5e15 galaxy_radians = calculate_arc() dist_m = lighyear_m * galaxy_radians * arc_len That looks a lot clearer to me than sticking together raw numbers, however spelled. On Aug 25, 2016 2:56 AM, "Joao S. O. Bueno" <jsbueno@python.org.br> wrote:
participants (4)
-
David Mertz -
Joao S. O. Bueno -
Ken Kundert -
Paul Moore