[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Serge Stroobandt added the comment: Dear Keith, that is exactly how it should be! (I cross-checked with a HP calculator to make sure.) -- ___ Python tracker

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Keith Brafford added the comment: Serge, I wrote this awhile back, before I learned you aren't supposed to subclass built-in types. Is this the type of effect you're looking for? https://gist.github.com/kbrafford/da39e06d18b6df2a0eecb4493699 Here's an example using it:

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Stefan Krah added the comment: On Fri, Aug 12, 2016 at 08:38:52PM +, Serge Stroobandt wrote: > This should not be that difficult to implement? > I promise, every six months an engineer will stop by here asking for this. > Instead of nagging, this could already have been implemented one way

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Serge Stroobandt added the comment: What most engineers would like to see implemented in Python is a new engineering notation identical to the one implemented in the omnipresent HP calculators. Quoting from the HP-15C Owner's Handbook: "- In engineering notation, the first significant digit

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Stefan Krah added the comment: On Thu, Aug 11, 2016 at 09:17:10AM +, Antti Haapala wrote: > However the *precision* of decimals is meaningless anyhow. Add a very > precisely measured '0e0' to any number and the sum also has exponent of 0, > and is thus never displayed in exponential

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Antti Haapala added the comment: Ok, after reading the "spec" it seems that the engineering exponent is indeed printed for positive exponents *if* the precision of the number is less than the digits of the exponent, which I didn't realize that I should be testing. However the *precision* of

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Stefan Krah added the comment: @Antti Please think before you write and stop making unfounded allegations. -- ___ Python tracker ___

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Antti Haapala added the comment: Indeed engineering notation is now utterly broken, the engineering notation is not printed for pretty much _any *engineering* numbers at all_ in 3.6. Engineering numbers mean numbers that could be met in an *engineering* context, not cosmological! --

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Raymond Hettinger added the comment: I'm disinclined to make a new method and instead prefer to go the route of having a formatting option. For the most part, we want the methods to be limited to those in the spec (the API is already huge). The other reason is that output formatting options

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Serge Stroobandt added the comment: Related issue: https://bugs.python.org/issue8060 -- ___ Python tracker ___

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Mark Dickinson added the comment: I also agree that we shouldn't change the current code. As Raymond says, it may be worth a doc change. Serge: I was confused by your initial report. If I understand the StackOverflow question correctly, this isn't about the output for *infinite* numbers

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Serge Stroobandt added the comment: Mark: Don't shoot the messenger! I literally quoted the implemented proprietary specification. However, I do agree that the term "numbers (or bases) with an infinte decimal representation" would be more appropriate in this context. Also, improving

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Stefan Krah added the comment: The spec was the only reasonable choice at the time decimal.py was written. Incidentally, it is basically IEEE-754-2008 with arbitrary precision extensions; this isn't surprising since Mike Cowlishaw was on the IEEE committee and wrote the spec at the same time.

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Raymond Hettinger added the comment: The decimal module strives to exactly follow the spec even when our sensibilities suggest otherwise. Perhaps, we can add a note to the current docs describing the situation. The API itself is a settled issue, that ship sailed a very long time ago (the

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Serge Stroobandt added the comment: An emphasized version of the exact quote is here now: http://stackoverflow.com/a/35045233/2192488 -- ___ Python tracker

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Eric V. Smith added the comment: Agreed. And, since any API change would just be a 3.6+ change, this would increase the difficulty of moving between 2.7 and 3.x. Which is not something we want. -- ___ Python tracker

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

New submission from Serge Stroobandt: In https://docs.python.org/2/library/string.html#formatstrings the proprietary (IBM) specifcation "Decimal Arithmetic Specification" http://www.gobosoft.com/eiffel/gobo/math/decimal/daconvs.html is incorrectly being heralded as "the" specifiaction for

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Serge Stroobandt added the comment: @rhettinger I completely agree with not creating a backward incompatibility at this point in time. The real issue is that decimal.to_eng_string() was written to a (unfortunately chosen) proprietary specification which does not entirely correspond to the

[issue26223] decimal.to_eng_string() does not implement engineering notation in all cases.

Changes by SilentGhost : -- versions: +Python 3.6 -Python 2.7 ___ Python tracker ___ ___