Native Python support for units?
Native Python support for units?
Posted Jul 13, 2022 7:15 UTC (Wed) by Karellen (subscriber, #67644)Parent article: Native Python support for units?
(They can of course be combined, 10e1j does indeed mean 100*sqrt(-1).)
Huh. I did not read 10e1j as indeed meaning (10e1)j. Rather, I read it as 10e(1j).
Posted Jul 13, 2022 7:50 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (10 responses)
Posted Jul 13, 2022 11:55 UTC (Wed)
by willy (subscriber, #9762)
[Link]
Posted Jul 13, 2022 17:05 UTC (Wed)
by Karellen (subscriber, #67644)
[Link] (8 responses)
I wonder, if it was written "10×10^1j", where would the precedence of the "j" go? Lower than "×"? Or equivalent but still applied last because of its rightmost position?
"Imaginary part" is always forgotten on the operation order-of-precedence lists. I wonder if it feels left out! :-)
Posted Jul 13, 2022 19:38 UTC (Wed)
by dtlin (subscriber, #36537)
[Link] (7 responses)
I don't really see the need for a postfix unit syntax. Using the usual * and / operators generalizes to stuff like "ft·lb" and "m/s" which would be awkward to express as single tokens. A library (such as Pint in the article or astropy.units mentioned below) with appropriate operator overloads should be enough.
Posted Jul 14, 2022 1:29 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
In Python (not math), the notation 10e1 is *not* a combined-multiplication-and-exponentiation operator applied to the arguments 10 and 1. Rather, it is another way of writing the float literal 100.0. Similarly, in Python, the j suffix is not a multiply-by-𝑖 postfix operator. Rather, it is the suffix for an imaginary literal. You cannot write some_varj and expect it to multiply some_var by 𝑖, nor can you write some_vare1 and expect it to multiply some_var by 10, because in both cases, the syntax is meant for constructing literals. This also means that both of these syntaxes have the highest possible precedence, since they're not proper operations at all, they're just literal notation. This cannot even be overridden by parentheses. 10e(1j) is a syntax error, not 10 × 10^𝑖. The latter can only be written explicitly using the * and ** operators (or equivalent functions from the cmath module).
To be even more pedantic: The imaginary literal syntax consists of a (real) float literal followed by the j suffix. So you have to parse a real literal before you can even deal with parsing an imaginary literal, and that's why the j has to bind less tightly than the e. If you had instead written 10 * 10 ** 1j, then the opposite would happen, and you really would get 10 × 10^𝑖 (i.e. the j binds more tightly than the exponent operator, contrary to PEMDAS and similar rules).
Posted Jul 30, 2022 16:53 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (5 responses)
Ten SQUARED is a hundred - 10e2.
Cheers,
Posted Jul 30, 2022 17:57 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (4 responses)
Posted Jul 30, 2022 20:34 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (3 responses)
But 10e1 is rather odd notation - 10 x 10^1
I'm used to either scientific notation where it's en and n is a multiple of 3, or (dunno what it's called) where 1 <= mantissa < 10.
( I know some people prefer the mantissa between 0 and 1, rather than 1 and 10, but the combination of mantissa not between 0 and ten, and exponent not a multiple of 3, is, well, weird!)
Cheers,
Posted Jul 30, 2022 23:51 UTC (Sat)
by rschroev (subscriber, #4164)
[Link] (1 responses)
When communicating with other people it's probably best to stick with either scientific notation in the strict sense (1 <= mantissa < 10) or engineering notation (exponent is a multiple of 3, 1 <= mantissa < 1000), but other representations are just as valid and programming languages don't care in the least how you scale the exponent.
Posted Jul 31, 2022 7:50 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
But brains usually do ... :-)
Cheers,
Posted Jul 31, 2022 17:21 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
Scientific pocket calculators (are these still a thing?) used to call the “1 ≤ mantissa < 10 and arbitrary exponent” style “scientific” and the “1 ≤ mantissa < 1000, exponent a multiple of 3” style “engineering”.
Posted Jul 22, 2022 9:54 UTC (Fri)
by Darkstar (guest, #28767)
[Link] (2 responses)
Posted Jul 22, 2022 13:58 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
"j" is used for the imaginary unit instead of "i" in any field where "i" would be potentially confusing. Electrical engineering, for example, uses "I" for currents, and so talking about an AC current of I = (5 + 3i) / (4 + 2i) has room for confusion when spoken, where I = (5 + 3j) / (4 + 2j) does not.
Posted Jul 23, 2022 7:02 UTC (Sat)
by smurf (subscriber, #17840)
[Link]
Also, well, Mathematicians use i while engineering uses j because i is either current or an index. Python had to choose one, so Guido picked j.
See also https://bugs.python.org/issue10562
Native Python support for units?
Native Python support for units?
Native Python support for units?
Native Python support for units?
Native Python support for units?
Native Python support for units?
Wol
Native Python support for units?
Don't you mean 10e1 is 10.0 - 10 to the power 1?
$ python3
Python 3.9.2 (default, Feb 28 2021, 17:03:44)
[GCC 10.2.1 20210110] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> 1e1
10.0
>>> 1e2
100.0
>>> 10e1
100.0
>>>
Native Python support for units?
Wol
Native Python support for units?
Native Python support for units?
Wol
Native Python support for units?
I'm used to either scientific notation where it's en and n is a multiple of 3, or (dunno what it's called) where 1 ≤ mantissa < 10.
Native Python support for units?
Native Python support for units?
Native Python support for units?