DOC describe the situation of extended precision in numpy

1 files changed, 37 insertions, 0 deletions

diff --git a/numpy/doc/basics.py b/numpy/doc/basics.py
index 86a3984c2..3d473da8f 100644
--- a/numpy/doc/basics.py
+++ b/numpy/doc/basics.py
@@ -142,5 +142,42 @@ 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 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 (for space or compatibility reasons). In spite
+of the names, these provide only as much precision as ``np.longdouble``,
+that is, 64 or 80 bits on x86 machines.
+
+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