Engineering numerical format PEP discussion
in [Python]
|
From: Chris Rebert on 26 Apr 2010 01:19 On Sun, Apr 25, 2010 at 9:42 PM, Keith <keith.brafford(a)gmail.com> wrote: > On Apr 26, 12:02Â am, Chris Rebert <c...(a)rebertia.com> wrote: >> On Sun, Apr 25, 2010 at 8:36 PM, 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. > Â snip >> Relevant related information: >> The Decimal datatype supports engineering format directly:http://docs.python.org/library/decimal.html#decimal.Decimal.to_eng_st... > > 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: http://speleotrove.com/decimal/decarith.pdf (to-engineering-string is on page 20 if you're interested) Cheers, Chris -- http://blog.rebertia.com
From: Chris Rebert on 26 Apr 2010 01:39 On Sun, Apr 25, 2010 at 10:25 PM, Xavier Ho <contact(a)xavierho.com> wrote: > On Mon, Apr 26, 2010 at 3:19 PM, Chris Rebert <clp2(a)rebertia.com> wrote: >> 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) >> > I just gave Page 20 a quick read, and it says: > >> if the number is non-zero, the converted exponent is adjusted to be a >> multiple of three (engineering notation) by positioning the decimal point >> with one, two, or three characters preceding it (that is, the part before >> the decimal point will range from 1 through 999); > > Obviously that would make  '1234567' not an Engineering notation? Well, I saw that too, but note how it's prefixed by (emphasis mine): "The conversion **exactly follows the rules for conversion to scientific numeric string** except in the case of finite numbers **where exponential notation is used.**" The description of to-scientific-string explains exactly when it uses exponential notation, but it gets slightly technical and I'm not interested enough, nor do I have the time at the moment, to read the entire spec. Cheers, Chris -- I hate RQAB-s http://blog.rebertia.com
From: Keith on 26 Apr 2010 01:47 On Apr 26, 1:19 am, Chris Rebert <c...(a)rebertia.com> wrote: > 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. snip > The spec:http://speleotrove.com/decimal/decarith.pdf > (to-engineering-string is on page 20 if you're interested) Thanks for that. I didn't realize that Mike Cowlishaw wrote the spec we're discussing. It's too bad OS/2 didn't fare better, or we'd possibly be discussing a proposal for a REP (Rexx Enhancement Proposal) ;-) 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' Regardless, given that the whole point of format specifiers (whether they are the traditional python 2.x/C style %[whatever] strings, or the new format() function) is to make it easy for you to format numbers for printing, wouldn't the language be better off if we added engineering notation to the features that already offer scientific notation? --Keith Brafford
From: Terry Reedy on 26 Apr 2010 02:23 On 4/25/2010 11:36 PM, Keith wrote: > I am considering writing a PEP for the inclusion of an engineering > format specifier, and would appreciate input from others. I tested that input is no problem, so the only question is output. > Do you think this idea has enough merit to make it to PEP status? I think it has enough merit to be considered. A minor addition to ..format() specifiers for 3.whenever would probably not require a PEP. (It is too late at night for me to think about anything concrete at the moment, though.) A concrete proposal on the python-ideas list might be enough. I am not sure if this would be covered by the current moratorium on core changes, though. Terry Jan Reedy
From: Stefan Krah on 26 Apr 2010 05:04
Chris Rebert <clp2(a)rebertia.com> wrote: > >>>> 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: http://speleotrove.com/decimal/decarith.pdf > (to-engineering-string is on page 20 if you're interested) The module is correct. Printing without exponent follows the same rules as to-scientific-string: "If the exponent is less than or equal to zero and the adjusted exponent is greater than or equal to -6, the number will be converted to a character form without using exponential notation." Stefan Krah |