expansion. For example, 1.1 decimal is binary \code{1.0001100110011
plus an infinite number of additional terms. IEEE 754 has to chop off
...}; .1 = 1/16 + 1/32 + 1/256 plus an infinite number of additional
that infinitely repeated decimal after 52 digits, so the
terms. IEEE 754 has to chop off that infinitely repeated decimal
representation is slightly inaccurate.
after 52 digits, so the representation is slightly inaccurate.
Sometimes you can see this inaccuracy when the number is printed:
Sometimes you can see this inaccuracy when the number is printed:
\begin{verbatim}
\begin{verbatim}
...
@@ -471,9 +472,10 @@ Sometimes you can see this inaccuracy when the number is printed:
...
@@ -471,9 +472,10 @@ Sometimes you can see this inaccuracy when the number is printed:
\end{verbatim}
\end{verbatim}
The inaccuracy isn't always visible when you print the number because
The inaccuracy isn't always visible when you print the number because
the FP-to-decimal-string conversion is provided by the C library and
the FP-to-decimal-string conversion is provided by the C library, and
most C libraries try to produce sensible output, but the inaccuracy is
most C libraries try to produce sensible output. Even if it's not
still there and subsequent operations can magnify the error.
displayed, however, the inaccuracy is still there and subsequent
operations can magnify the error.
For many applications this doesn't matter. If I'm plotting points and
For many applications this doesn't matter. If I'm plotting points and
displaying them on my monitor, the difference between 1.1 and
displaying them on my monitor, the difference between 1.1 and
...
@@ -483,6 +485,8 @@ number to two or three or even eight decimal places, the error is
...
@@ -483,6 +485,8 @@ number to two or three or even eight decimal places, the error is
never apparent. However, for applications where it does matter,
never apparent. However, for applications where it does matter,
it's a lot of work to implement your own custom arithmetic routines.
it's a lot of work to implement your own custom arithmetic routines.
Hence, the \class{Decimal} type was created.
\subsection{The \class{Decimal} type}
\subsection{The \class{Decimal} type}
A new module, \module{decimal}, was added to Python's standard library.
A new module, \module{decimal}, was added to Python's standard library.
...
@@ -490,8 +494,10 @@ It contains two classes, \class{Decimal} and \class{Context}.
...
@@ -490,8 +494,10 @@ It contains two classes, \class{Decimal} and \class{Context}.
\class{Decimal} instances represent numbers, and
\class{Decimal} instances represent numbers, and
\class{Context} instances are used to wrap up various settings such as the precision and default rounding mode.
\class{Context} instances are used to wrap up various settings such as the precision and default rounding mode.
\class{Decimal} instances, like regular Python integers and FP numbers, are immutable; once they've been created, you can't change the value it represents.
\class{Decimal} instances, like regular Python integers and FP
\class{Decimal} instances can be created from integers or strings:
numbers, are immutable; once they've been created, you can't change
the value it represents. \class{Decimal} instances can be created
from integers or strings:
\begin{verbatim}
\begin{verbatim}
>>> import decimal
>>> import decimal
...
@@ -501,22 +507,24 @@ Decimal("1972")
...
@@ -501,22 +507,24 @@ Decimal("1972")
Decimal("1.1")
Decimal("1.1")
\end{verbatim}
\end{verbatim}
You can also provide tuples containing the sign, mantissa represented
You can also provide tuples containing the sign, the mantissa represented
as a tuple of decimal digits, and exponent:
as a tuple of decimal digits, and the exponent:
\begin{verbatim}
\begin{verbatim}
>>> decimal.Decimal((1, (1, 4, 7, 5), -2))
>>> decimal.Decimal((1, (1, 4, 7, 5), -2))
Decimal("-14.75")
Decimal("-14.75")
\end{verbatim}
\end{verbatim}
Cautionary note: the sign bit is a Boolean value, so 0 is positive and 1 is negative.
Cautionary note: the sign bit is a Boolean value, so 0 is positive and
1 is negative.
Floating-point numbers posed a bit of a problem: should the FP number
Converting from floating-point numbers poses a bit of a problem:
representing 1.1 turn into the decimal number for exactly 1.1, or for
should the FP number representing 1.1 turn into the decimal number for
1.1 plus whatever inaccuracies are introduced? The decision was to
exactly 1.1, or for 1.1 plus whatever inaccuracies are introduced?
leave such a conversion out of the API. Instead, you should convert
The decision was to leave such a conversion out of the API. Instead,
the floating-point number into a string using the desired precision and
you should convert the floating-point number into a string using the
pass the string to the \class{Decimal} constructor:
desired precision and pass the string to the \class{Decimal}