Decimal FAQ
-----------
-Q. It is cumbersome to type ``decimal.Decimal('1234.5')``. Is there a way to
+Q: It is cumbersome to type ``decimal.Decimal('1234.5')``. Is there a way to
minimize typing when using the interactive interpreter?
-A. Some users abbreviate the constructor to just a single letter:
+A: Some users abbreviate the constructor to just a single letter:
>>> D = decimal.Decimal
>>> D('1.23') + D('3.45')
Decimal('4.68')
-Q. In a fixed-point application with two decimal places, some inputs have many
+Q: In a fixed-point application with two decimal places, some inputs have many
places and need to be rounded. Others are not supposed to have excess digits
and need to be validated. What methods should be used?
-A. The :meth:`~Decimal.quantize` method rounds to a fixed number of decimal places. If
+A: The :meth:`~Decimal.quantize` method rounds to a fixed number of decimal places. If
the :const:`Inexact` trap is set, it is also useful for validation:
>>> TWOPLACES = Decimal(10) ** -2 # same as Decimal('0.01')
...
Inexact: None
-Q. Once I have valid two place inputs, how do I maintain that invariant
+Q: Once I have valid two place inputs, how do I maintain that invariant
throughout an application?
-A. Some operations like addition, subtraction, and multiplication by an integer
+A: Some operations like addition, subtraction, and multiplication by an integer
will automatically preserve fixed point. Others operations, like division and
non-integer multiplication, will change the number of decimal places and need to
be followed-up with a :meth:`~Decimal.quantize` step:
>>> div(b, a)
Decimal('0.03')
-Q. There are many ways to express the same value. The numbers ``200``,
+Q: There are many ways to express the same value. The numbers ``200``,
``200.000``, ``2E2``, and ``.02E+4`` all have the same value at
various precisions. Is there a way to transform them to a single recognizable
canonical value?
-A. The :meth:`~Decimal.normalize` method maps all equivalent values to a single
+A: The :meth:`~Decimal.normalize` method maps all equivalent values to a single
representative:
>>> values = map(Decimal, '200 200.000 2E2 .02E+4'.split())
>>> [v.normalize() for v in values]
[Decimal('2E+2'), Decimal('2E+2'), Decimal('2E+2'), Decimal('2E+2')]
-Q. When does rounding occur in a computation?
+Q: When does rounding occur in a computation?
-A. It occurs *after* the computation. The philosophy of the decimal
+A: It occurs *after* the computation. The philosophy of the decimal
specification is that numbers are considered exact and are created
independent of the current context. They can even have greater
precision than current context. Computations process with those
>>> pi + 0 - Decimal('0.00005'). # Intermediate values are rounded
Decimal('3.1416')
-Q. Some decimal values always print with exponential notation. Is there a way
+Q: Some decimal values always print with exponential notation. Is there a way
to get a non-exponential representation?
-A. For some values, exponential notation is the only way to express the number
+A: For some values, exponential notation is the only way to express the number
of significant places in the coefficient. For example, expressing
``5.0E+3`` as ``5000`` keeps the value constant but cannot show the
original's two-place significance.
>>> remove_exponent(Decimal('5E+3'))
Decimal('5000')
-Q. Is there a way to convert a regular float to a :class:`Decimal`?
+Q: Is there a way to convert a regular float to a :class:`Decimal`?
-A. Yes, any binary floating-point number can be exactly expressed as a
+A: Yes, any binary floating-point number can be exactly expressed as a
Decimal though an exact conversion may take more precision than intuition would
suggest:
>>> Decimal(math.pi)
Decimal('3.141592653589793115997963468544185161590576171875')
-Q. Within a complex calculation, how can I make sure that I haven't gotten a
+Q: Within a complex calculation, how can I make sure that I haven't gotten a
spurious result because of insufficient precision or rounding anomalies.
-A. The decimal module makes it easy to test results. A best practice is to
+A: The decimal module makes it easy to test results. A best practice is to
re-run calculations using greater precision and with various rounding modes.
Widely differing results indicate insufficient precision, rounding mode issues,
ill-conditioned inputs, or a numerically unstable algorithm.
-Q. I noticed that context precision is applied to the results of operations but
+Q: I noticed that context precision is applied to the results of operations but
not to the inputs. Is there anything to watch out for when mixing values of
different precisions?
-A. Yes. The principle is that all values are considered to be exact and so is
+A: Yes. The principle is that all values are considered to be exact and so is
the arithmetic on those values. Only the results are rounded. The advantage
for inputs is that "what you type is what you get". A disadvantage is that the
results can look odd if you forget that the inputs haven't been rounded:
>>> Context(prec=5, rounding=ROUND_DOWN).create_decimal('1.2345678')
Decimal('1.2345')
-Q. Is the CPython implementation fast for large numbers?
+Q: Is the CPython implementation fast for large numbers?
-A. Yes. In the CPython and PyPy3 implementations, the C/CFFI versions of
+A: Yes. In the CPython and PyPy3 implementations, the C/CFFI versions of
the decimal module integrate the high speed `libmpdec
<https://www.bytereef.org/mpdecimal/doc/libmpdec/index.html>`_ library for
arbitrary precision correctly rounded decimal floating-point arithmetic [#]_.
projects / thirdparty / Python / cpython.git / commitdiff
