Engineering numerical format PEP discussion
in [Python]
|
From: Keith on 26 Apr 2010 20:42 On Apr 26, 5:33 am, Stefan Krah <stefan-use...(a)bytereef.org> wrote: > Keith <keith.braff...(a)gmail.com> wrote: > > Even though this uses the to_eng_string() function, and even though I > > am using the decimal.Context class: > > > >>> c = decimal.Context(prec=5) > > >>> decimal.Decimal(1234567).to_eng_string(c) > > '1234567' > > > That is not an engineering notation string. > > To clarify further: The spec says that the printing functions are not > context sensitive, so to_eng_string does not *apply* the context. > > The context is only passed in for the 'capitals' value, which determines > whether the exponent letter is printed in lower or upper case. > > This is one of the unfortunate situations where passing a context can > create great confusion for the user. Another one is: > > >>> c = Context(prec=5) > >>> Decimal(12345678, c) > > Decimal('12345678') > > Here the context is passed only for the 'flags' and 'traps' members: > > >>> Decimal("wrong", c) > > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "/usr/lib/python3.2/decimal.py", line 548, in __new__ > "Invalid literal for Decimal: %r" % value) > File "/usr/lib/python3.2/decimal.py", line 3836, in _raise_error > raise error(explanation) > decimal.InvalidOperation: Invalid literal for Decimal: 'wrong' > > >>>c.traps[InvalidOperation] = False > >>> Decimal("wrong", c) > > Decimal('NaN') > > Stefan Krah Thank you for that illustrative clarification, Stefan. I should not have used decimal.Context in that case, nor should I have implied that it would have helped prove my case. --Keith Brafford
From: MRAB on 26 Apr 2010 20:47 Mark Dickinson wrote: > On Apr 26, 4:36 am, Keith <keith.braff...(a)gmail.com> wrote: >> I am considering writing a PEP for the inclusion of an engineering >> format specifier, and would appreciate input from others. > >> [...] > >> I am thinking that if we simply added something like %n (for eNgineer) >> to the list of format specifiers that we could make life easier for >> engineers: >> >> ("%n" % 12345) == "12.345e+03" >> ("%n" % 1234) == "1.234e+03" >> ("%n" % 123) == "123e+00" >> ("%n" % 1.2345e-5) == "12.345e+06" > > I don't think there's much chance of getting changes to old-style > string formatting accepted; you might be better off aiming at the new- > style string formatting. (And there, the 'n' modifier is already > taken for internationalization, so you'd have to find something > different. :) > "e" is already used, "n" is already used, "g" is already used, etc "t" for "powers of a thousand", perhaps? (Or "m"?)
From: Keith on 26 Apr 2010 21:12 On Apr 26, 7:56 pm, Mark Dickinson <dicki...(a)gmail.com> wrote: > On Apr 26, 6:47 am, Keith <keith.braff...(a)gmail.com> wrote: > > > From that document it appears that my decimal.Decimal(1234567) example > > shows that the module has a bug: > > > Doc says: > > [0,123,3] ===> "123E+3" > > > But Python does:>>> import decimal > > >>> decimal.Decimal(123000).to_eng_string() > > > '123000' > > That's not a bug. The triple [0,123,3] is Decimal('123e3'), which is > not the same thing as Decimal('123000'). The former has an exponent > of 3 (in the language of the specification), while the latter has an > exponent of 0. > > >>> decimal.Decimal('123e3').to_eng_string() > > '123E+3' > > -- > Mark Thanks, Mark, you're right. It's clear that Decimal.to_eng_string() doesn't solve the problem that I am trying to solve, which is: take the Python "float" type, and print it in engineering format. --Keith Brafford
From: Keith on 26 Apr 2010 21:16 On Apr 26, 8:47 pm, MRAB <pyt...(a)mrabarnett.plus.com> wrote: > "t" for "powers of a thousand", perhaps? (Or "m"?) Both of those letters are fine. I kinda like "m" for the whole Greco- Roman angle, now that you point it out :-) --Keith Brafford
From: Lie Ryan on 27 Apr 2010 05:59
On 04/27/10 10:36, Keith wrote: > I think it's worth making the print statement (or print function, as > the case may be) let us do engineering notation, just like it lets us > specify scientific notation. The print statement/function does no magic at all in specifying how numbers look like when. The apparently magical formatting is done by the %-operator and for {}-style formatting, the obj.__format__(). If you're using the {}-format, you can override .__format__() to define your own formatting mini-language. If you need to, you can monkey patch format() so that it wraps int/float in Engineer wrapper that defines Engineer.__format__() to whatever formatting style you're using. |