some notes on float precision

git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@30424 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Hartmut Holzgraefe 2000-08-17 19:24:36 +00:00
parent 3fbfd4ebbb
commit aa3b2dd31a
2 changed files with 34 additions and 4 deletions

View file

@ -307,8 +307,8 @@ $binary = base_convert ($hexadecimal, 16, 2);
get the old behaviour.
</simpara>
<simpara>
See also <function>floor</function> and
<function>round</function>.
See also <function>floor</function> and <function>round</function>
and the <link linkend="warn.float-precision">float precision note</link>.
</simpara>
</refsect1>
</refentry>
@ -478,8 +478,8 @@ $binary = base_convert ($hexadecimal, 16, 2);
get the old behaviour.
</simpara>
<simpara>
See also <function>ceil</function> and
<function>round</function>.
See also <function>ceil</function> and <function>round</function>
and the <link linkend="warn.float-precision">float precision note</link>.
</simpara>
</refsect1>
</refentry>

View file

@ -62,6 +62,9 @@ $a = 0123; # octal number (equivalent to 83 decimal)
$a = 0x12; # hexadecimal number (equivalent to 18 decimal)
</programlisting>
</informalexample>
The size of an integer is platform-dependant, although a
maximum value of about 2 billion is the usual value
(thats 32 bits signed).
</para>
</sect1>
@ -75,7 +78,34 @@ $a = 0x12; # hexadecimal number (equivalent to 18 decimal)
$a = 1.234; $a = 1.2e3;
</programlisting>
</informalexample>
The size of a floating point number is platform-dependant,
although a maximum of ~1.8e308 with a precision of roughly 14
decimal digits is a common value (thats 64 bit IEEE format).
</para>
<warning id="warn.float-precision">
<para>
It is quite usual that simple decimal fractions like 0.1 or 0.7
cannot be converted into their internal binary counterparts
without a little lack of precision. This can lead to confusing
results as for example <literal>floor((0.1+0.7)*10)</literal>
will usualy return <literal>7</literal> instead of the expexted
<literal>8</literal> as the result of the inner expression
really something like <literal>7.9999999999...</literal>.
</para>
<para>
This is similar to the impossibility of writing down the result
of <literal>1/3</literal> exactly in decimal form with a limit
numer of digits as it is <literal>0.3333333...</literal>.
</para>
<para>
So never trust floating number results to the last digit and
never compare floating point numbers for equalness. If you
really need higher precision for decimal calculations or
in general you should use the
<link linkend="ref.bc">arbitrary precision math functions</link>
instead.
</para>
</warning>
</sect1>
<sect1 id="language.types.string">