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
that was probably intended::
>>> 0.2
0.20000000000000001
>>> print 0.2
>>> 1.1 - 0.9
0.20000000000000007
>>> print 1.1 - 0.9
0.2
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.
* Decimal numbers can be represented exactly. In contrast, numbers like
:const:`1.1` do not have an exact representation in binary floating point. End
users typically would not expect :const:`1.1` to display as
:const:`1.1000000000000001` as it does with binary floating point.
:const:`1.1` and :const:`2.2` do not have an exact representations in binary
floating point. End users typically would not expect ``1.1 + 2.2`` to display
as :const:`3.3000000000000003` as it does with binary floating point.
* 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
@ -193,7 +193,7 @@ floating point flying circus:
>>> str(a)
'1.34'
>>> float(a)
1.3400000000000001
1.34
>>> round(a, 1) # round() first converts to binary floating point
1.3
>>> int(a)

View File

@ -90,7 +90,7 @@ Number-theoretic and representation functions
loss of precision by tracking multiple intermediate partial sums::
>>> 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])
1.0

View File

@ -83,7 +83,7 @@ This example uses the iterator form::
>>> for row in c:
... 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-04-06', u'SELL', u'IBM', 500, 53.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 'sqlite3.Row'>
>>> 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)
5
>>> r[2]

View File

@ -875,7 +875,7 @@ Color control
>>> tup = (0.2, 0.8, 0.55)
>>> turtle.pencolor(tup)
>>> turtle.pencolor()
(0.20000000000000001, 0.80000000000000004, 0.5490196078431373)
(0.2, 0.8, 0.5490196078431373)
>>> colormode(255)
>>> turtle.pencolor()
(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.99999999999999989
0.9999999999999999
Binary floating-point arithmetic holds many surprises like this. The problem
with "0.1" is explained in precise detail below, in the "Representation Error"

View File

@ -49,10 +49,10 @@ Some examples::
'Hello, world.'
>>> repr(s)
"'Hello, world.'"
>>> str(0.1)
'0.1'
>>> repr(0.1)
'0.10000000000000001'
>>> str(1.0/7.0)
'0.142857142857'
>>> repr(1.0/7.0)
'0.14285714285714285'
>>> x = 10 * 3.25
>>> y = 200 * 200
>>> 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::
>>> from decimal import *
>>> Decimal('0.70') * Decimal('1.05')
>>> x = Decimal('0.70') * Decimal('1.05')
>>> x
Decimal('0.7350')
>>> .70 * 1.05
0.73499999999999999
>>> x.quantize(Decimal('0.01')) # round to nearest cent
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
place significance from multiplicands with two place significance. Decimal