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 <rep...@bugs.python.org>
<http://bugs.python.org/i
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
Serge Stroobandt added the comment:
As per https://bugs.python.org/issue26223#msg259772 , can we please reopen this?
I kind of hate it when *real* issues are kept closed for years (6!) until
another lost soul comes by with the same itch...
--
nosy: +serge.stroobandt
versions: +Python
Serge Stroobandt added the comment:
Related issue:
https://bugs.python.org/issue8060
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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,
Serge Stroobandt added the comment:
An emphasized version of the exact quote is here now:
http://stackoverflow.com/a/35045233/2192488
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
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
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
