summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorCharles Harris <charlesr.harris@gmail.com>2015-09-10 12:03:28 -0600
committerCharles Harris <charlesr.harris@gmail.com>2015-09-10 12:03:28 -0600
commit4eb2dbc32a6d3528fdb30b86874fc874f499a93d (patch)
treec5ae470ee30a5be23345756b42227c70f6fae4f8
parent0b0206c1617841ed2e5324de752ee8ede2cce791 (diff)
parent088302a93e7e95139598c37a97d2faadb7a688ac (diff)
downloadnumpy-4eb2dbc32a6d3528fdb30b86874fc874f499a93d.tar.gz
Merge pull request #6262 from aarchiba/longdouble_docs
DOC describe the situation of extended precision in numpy
-rw-r--r--numpy/doc/basics.py39
1 files changed, 39 insertions, 0 deletions
diff --git a/numpy/doc/basics.py b/numpy/doc/basics.py
index 86a3984c2..745bff15a 100644
--- a/numpy/doc/basics.py
+++ b/numpy/doc/basics.py
@@ -142,5 +142,44 @@ identical behaviour between arrays and scalars, irrespective of whether the
value is inside an array or not. NumPy scalars also have many of the same
methods arrays do.
+Extended Precision
+==================
+
+Python's floating-point numbers are usually 64-bit floating-point numbers,
+nearly equivalent to ``np.float64``. In some unusual situations it may be
+useful to use floating-point numbers with more precision. Whether this
+is possible in numpy depends on the hardware and on the development
+environment: specifically, x86 machines provide hardware floating-point
+with 80-bit precision, and while most C compilers provide this as their
+``long double`` type, MSVC (standard for Windows builds) makes
+``long double`` identical to ``double`` (64 bits). Numpy makes the
+compiler's ``long double`` available as ``np.longdouble`` (and
+``np.clongdouble`` for the complex numbers). You can find out what your
+numpy provides with``np.finfo(np.longdouble)``.
+
+Numpy does not provide a dtype with more precision than C
+``long double``s; in particular, the 128-bit IEEE quad precision
+data type (FORTRAN's ``REAL*16``) is not available.
+
+For efficient memory alignment, ``np.longdouble`` is usually stored
+padded with zero bits, either to 96 or 128 bits. Which is more efficient
+depends on hardware and development environment; typically on 32-bit
+systems they are padded to 96 bits, while on 64-bit systems they are
+typically padded to 128 bits. ``np.longdouble`` is padded to the system
+default; ``np.float96`` and ``np.float128`` are provided for users who
+want specific padding. In spite of the names, ``np.float96`` and
+``np.float128`` provide only as much precision as ``np.longdouble``,
+that is, 80 bits on most x86 machines and 64 bits in standard
+Windows builds.
+
+Be warned that even if ``np.longdouble`` offers more precision than
+python ``float``, it is easy to lose that extra precision, since
+python often forces values to pass through ``float``. For example,
+the ``%`` formatting operator requires its arguments to be converted
+to standard python types, and it is therefore impossible to preserve
+extended precision even if many decimal places are requested. It can
+be useful to test your code with the value
+``1 + np.finfo(np.longdouble).eps``.
+
"""
from __future__ import division, absolute_import, print_function