[Python-checkins] python/nondist/peps pep-0327.txt,1.3,1.4

rhettinger at users.sourceforge.net rhettinger at users.sourceforge.net
Tue Jun 29 23:37:15 EDT 2004


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




More information about the Python-checkins mailing list