Engineering numerical format PEP discussion

cassiope fpm at
Tue Apr 27 17:24:50 CEST 2010

On Apr 25, 10:19 pm, Chris Rebert <c... at> wrote:
> On Sun, Apr 25, 2010 at 9:42 PM, Keith <keith.braff... at> wrote:
> > On Apr 26, 12:02 am, Chris Rebert <c... at> wrote:
> >> On Sun, Apr 25, 2010 at 8:36 PM, Keith <keith.braff... at> wrote:
> >> > I am considering writing a PEP for the inclusion of an engineering
> >> > format specifier, and would appreciate input from others.
> >  snip
> >> Relevant related information:
> >> The Decimal datatype supports engineering format directly:
> > Thanks for pointing that out.  Does the engineering community get by
> > with the decimal module?
> > 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.
> 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:
> (to-engineering-string is on page 20 if you're interested)
> Cheers,
> Chris
> --

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.


More information about the Python-list mailing list