Engineering numerical format PEP discussion

[Lie Ryan]

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"?)

or perhaps as an extension to 'e', activated by '3e' (but that's
occupied for adding spaces, need to think of another way...)

 

[Gregory Ewing]

I kinda like "m" for the whole Greco-
Roman angle, now that you point it out

I like "m", too.

 

[Mark Dickinson]

Both of those letters are fine.  I kinda like "m" for the whole Greco-
Roman angle, now that you point it out

By the way, there's already a feature request open for this:

http://bugs.python.org/issue8060

That might be a good place to hash out the precise semantics. If you
could provide unit tests and/or an implementation that would likely
help move the issue along.

Mark

 

[cassiope]

Apparently either you and the General Decimal Arithmetic spec differ
on what constitutes engineering notation, there's a bug in the Python
decimal library, or you're hitting some obscure part of the spec's
definition. I don't have the expertise to know which is the case.

The spec:http://speleotrove.com/decimal/decarith.pdf
(to-engineering-string is on page 20 if you're interested)

Cheers,
Chris
--http://blog.rebertia.com

As has been pointed out, the Decimal implementation may not have all
the features desired (i.e. forcing a particular "exponent", or a
particular number of significant digits). Perhaps it could be
enhanced. The other concern is computational complexity - having to
perform complex engineering calculations in Decimal form is presumably
more burdensome than in floats.

What I've done for years is to have a function that converts an
arbitrary float into a string. The function has an optional parameter
that specifies the number of digits of the output.
Isn't as "automatic", of course, probably showing its C origins.

-f

 

[Keith]

By the way, there's already a feature request open for this:

http://bugs.python.org/issue8060

That might be a good place to hash out the precise semantics.  If you
could provide unit tests and/or an implementation that would likely
help move the issue along.

Mark

Oh nice! I don't know how I missed that.

--Keith Brafford

 

[Eike Welk]

I am considering writing a PEP for the inclusion of an engineering
format specifier, and would appreciate input from others.

I think it's a good idea. I regularly type numbers into my pocket calculator
just to do this conversion.


Eike.