Fix some documentation examples involving the repr of a float.

This commit is contained in:
Mark Dickinson 2009-11-24 14:27:02 +00:00
parent 9a03f2fd03
commit 6b87f117ca
8 changed files with 22 additions and 19 deletions

View file

@ -75,9 +75,9 @@ necessary to make ``eval(repr(f)) == f`` true for any float f. The ``str()``
function prints fewer digits and this often results in the more sensible number function prints fewer digits and this often results in the more sensible number
that was probably intended:: that was probably intended::
>>> 0.2 >>> 1.1 - 0.9
0.20000000000000001 0.20000000000000007
>>> print 0.2 >>> print 1.1 - 0.9
0.2 0.2
One of the consequences of this is that it is error-prone to compare the result One of the consequences of this is that it is error-prone to compare the result

View file

@ -35,9 +35,9 @@ arithmetic. It offers several advantages over the :class:`float` datatype:
people learn at school." -- excerpt from the decimal arithmetic specification. people learn at school." -- excerpt from the decimal arithmetic specification.
* Decimal numbers can be represented exactly. In contrast, numbers like * Decimal numbers can be represented exactly. In contrast, numbers like
:const:`1.1` do not have an exact representation in binary floating point. End :const:`1.1` and :const:`2.2` do not have an exact representations in binary
users typically would not expect :const:`1.1` to display as floating point. End users typically would not expect ``1.1 + 2.2`` to display
:const:`1.1000000000000001` as it does with binary floating point. as :const:`3.3000000000000003` as it does with binary floating point.
* The exactness carries over into arithmetic. In decimal floating point, ``0.1 * The exactness carries over into arithmetic. In decimal floating point, ``0.1
+ 0.1 + 0.1 - 0.3`` is exactly equal to zero. In binary floating point, the result + 0.1 + 0.1 - 0.3`` is exactly equal to zero. In binary floating point, the result
@ -193,7 +193,7 @@ floating point flying circus:
>>> str(a) >>> str(a)
'1.34' '1.34'
>>> float(a) >>> float(a)
1.3400000000000001 1.34
>>> round(a, 1) # round() first converts to binary floating point >>> round(a, 1) # round() first converts to binary floating point
1.3 1.3
>>> int(a) >>> int(a)

View file

@ -90,7 +90,7 @@ Number-theoretic and representation functions
loss of precision by tracking multiple intermediate partial sums:: loss of precision by tracking multiple intermediate partial sums::
>>> sum([.1, .1, .1, .1, .1, .1, .1, .1, .1, .1]) >>> sum([.1, .1, .1, .1, .1, .1, .1, .1, .1, .1])
0.99999999999999989 0.9999999999999999
>>> fsum([.1, .1, .1, .1, .1, .1, .1, .1, .1, .1]) >>> fsum([.1, .1, .1, .1, .1, .1, .1, .1, .1, .1])
1.0 1.0

View file

@ -83,7 +83,7 @@ This example uses the iterator form::
>>> for row in c: >>> for row in c:
... print row ... print row
... ...
(u'2006-01-05', u'BUY', u'RHAT', 100, 35.140000000000001) (u'2006-01-05', u'BUY', u'RHAT', 100, 35.14)
(u'2006-03-28', u'BUY', u'IBM', 1000, 45.0) (u'2006-03-28', u'BUY', u'IBM', 1000, 45.0)
(u'2006-04-06', u'SELL', u'IBM', 500, 53.0) (u'2006-04-06', u'SELL', u'IBM', 500, 53.0)
(u'2006-04-05', u'BUY', u'MSOFT', 1000, 72.0) (u'2006-04-05', u'BUY', u'MSOFT', 1000, 72.0)
@ -601,7 +601,7 @@ Now we plug :class:`Row` in::
>>> type(r) >>> type(r)
<type 'sqlite3.Row'> <type 'sqlite3.Row'>
>>> r >>> r
(u'2006-01-05', u'BUY', u'RHAT', 100.0, 35.140000000000001) (u'2006-01-05', u'BUY', u'RHAT', 100.0, 35.14)
>>> len(r) >>> len(r)
5 5
>>> r[2] >>> r[2]

View file

@ -875,7 +875,7 @@ Color control
>>> tup = (0.2, 0.8, 0.55) >>> tup = (0.2, 0.8, 0.55)
>>> turtle.pencolor(tup) >>> turtle.pencolor(tup)
>>> turtle.pencolor() >>> turtle.pencolor()
(0.20000000000000001, 0.80000000000000004, 0.5490196078431373) (0.2, 0.8, 0.5490196078431373)
>>> colormode(255) >>> colormode(255)
>>> turtle.pencolor() >>> turtle.pencolor()
(51, 204, 140) (51, 204, 140)

View file

@ -115,7 +115,7 @@ Another consequence is that since 0.1 is not exactly 1/10, summing ten values of
... sum += 0.1 ... sum += 0.1
... ...
>>> sum >>> sum
0.99999999999999989 0.9999999999999999
Binary floating-point arithmetic holds many surprises like this. The problem Binary floating-point arithmetic holds many surprises like this. The problem
with "0.1" is explained in precise detail below, in the "Representation Error" with "0.1" is explained in precise detail below, in the "Representation Error"

View file

@ -49,10 +49,10 @@ Some examples::
'Hello, world.' 'Hello, world.'
>>> repr(s) >>> repr(s)
"'Hello, world.'" "'Hello, world.'"
>>> str(0.1) >>> str(1.0/7.0)
'0.1' '0.142857142857'
>>> repr(0.1) >>> repr(1.0/7.0)
'0.10000000000000001' '0.14285714285714285'
>>> x = 10 * 3.25 >>> x = 10 * 3.25
>>> y = 200 * 200 >>> y = 200 * 200
>>> s = 'The value of x is ' + repr(x) + ', and y is ' + repr(y) + '...' >>> s = 'The value of x is ' + repr(x) + ', and y is ' + repr(y) + '...'

View file

@ -362,10 +362,13 @@ results in decimal floating point and binary floating point. The difference
becomes significant if the results are rounded to the nearest cent:: becomes significant if the results are rounded to the nearest cent::
>>> from decimal import * >>> from decimal import *
>>> Decimal('0.70') * Decimal('1.05') >>> x = Decimal('0.70') * Decimal('1.05')
>>> x
Decimal('0.7350') Decimal('0.7350')
>>> .70 * 1.05 >>> x.quantize(Decimal('0.01')) # round to nearest cent
0.73499999999999999 Decimal('0.74')
>>> round(.70 * 1.05, 2) # same calculation with floats
0.73
The :class:`Decimal` result keeps a trailing zero, automatically inferring four The :class:`Decimal` result keeps a trailing zero, automatically inferring four
place significance from multiplicands with two place significance. Decimal place significance from multiplicands with two place significance. Decimal