- Fixed inaccurate information on floats. Closes bug #53365.

git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@305581 c90b9560-bf6c-de11-be94-00142212c4b1

language/types/float.xml

@@ -44,20 +44,25 @@ EXPONENT_DNUM [+-]?(({LNUM} | {DNUM}) [eE][+-]? {LNUM})
   <title>Floating point precision</title>
 
   <para>
-   It is typical that simple decimal fractions like <literal>0.1</literal> or
-   <literal>0.7</literal> cannot be converted into their internal binary
+   Floating point numbers have limited precision. Although it depends on the
+   system, PHP typically uses the IEEE 754 double precision format, which will
+   give a maximum relative error due to rounding in the order of 1.11e-16.
+   Non elementary arithmetic operations may give larger errors, and, of course,
+   error progragation must be considered when several operations are
+   compounded.
+  </para>
+  
+  <para>
+   Additionally, rational numbers that are exactly representable as floating
+   point numbers in base 10, like <literal>0.1</literal> or
+   <literal>0.7</literal>, do not have an exact representation as floating
+   point numbers in base 2, which is used internally, no matter the size of
+   the mantissa. Hence, they cannot be converted into their internal binary
    counterparts without a small loss of precision. This can lead to confusing
    results: for example, <literal>floor((0.1+0.7)*10)</literal> will usually
    return <literal>7</literal> instead of the expected <literal>8</literal>,
    since the internal representation will be something like
-   <literal role="infdec">7.9</literal>.
-  </para>
-
-  <para>
-   This is due to the fact that it is impossible to express some
-   fractions in decimal notation with a finite number of digits. For instance,
-   <literal>1/3</literal> in decimal form becomes
-   <literal role="infdec">0.3</literal>.
+   <literal>7.9999999999999991118...</literal>.
   </para>
 
   <para>