Update of /cvsroot/python/python/nondist/peps In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24012 Modified Files: pep-0327.txt Log Message: Update the PEP to reflect the most recent decisions about interactions with binary floating point. Also document the rationale for the decisions. Index: pep-0327.txt =================================================================== RCS file: /cvsroot/python/python/nondist/peps/pep-0327.txt,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -d -r1.3 -r1.4 *** pep-0327.txt 16 Jun 2004 14:27:00 -0000 1.3 --- pep-0327.txt 30 Jun 2004 03:37:13 -0000 1.4 *************** *** 551,554 **** --- 551,581 ---- Decimal.from_float(1.1): The same as doing Decimal('1100000000000000088817841970012523233890533447265625e-51'). + Based on later discussions, it was decided to omit from_float() from the + API for Py2.4. Several ideas contributed to the thought process: + + - Interactions between decimal and binary floating point force the user to + deal with tricky issues of representation and round-off. Avoidance of those + issues is a primary reason for having the module in the first place. + + - The first release of the module should focus on that which is safe, minimal, + and essential. + + - While theoretically nice, real world use cases for interactions between + and decimals are lacking. Java included float/decimal conversions to handle + an obscure case where calculations are best performed in decimal eventhough + a legacy data structure requires the inputs and outputs to be stored in + binary floating point. + + - If the need arises, users can use string representations as an intermediate + type. The advantage of this approach is that it makes explicit the + assumptions about precision and representation (no wondering what is going + on under the hood). + + - The Java docs for BigDecimal(double val) reflected their experiences with + the constructor:: + + The results of this constructor can be somewhat + unpredictable and its use is generally not recommended. + From tuples *************** *** 723,732 **** accuracy, and range than float. ! But in Python it's OK to do ``35 + 1.1``, so why can't I do ! ``Decimal(35) + 1.1``? We agree that when a naive user writes ``1.1`` ! doesn't know that he's being inexact, but that happens in the both ! examples I just mentioned. ! So, what should we do? I propose to allow the interaction with float, making an exact conversion and raising ValueError if exceeds the precision in the current context (this is maybe too tricky, because --- 750,762 ---- accuracy, and range than float. ! The example of the valid python expression, ``35 + 1.1``, seems to suggest ! that ``Decimal(35) + 1.1`` should also be valid. However, a closer look ! shows that it only demonstrates the feasibility of integer to floating ! point conversions. Hence, the correct analog for decimal floating point ! is ``35 + Decimal(1.1)``. Both coercions, int-to-float and int-to-Decimal, ! can be done without incurring representation error. ! The question of how to coerce between binary and decimal floating point ! is more complex. I proposed allowing the interaction with float, making an exact conversion and raising ValueError if exceeds the precision in the current context (this is maybe too tricky, because