sigmasternchen/php-doc-en
1
0
Fork 0
mirror of https://github.com/sigmasternchen/php-doc-en synced 2025-03-16 08:58:56 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Small typo/clarification/indentation fixes.

Browse source 
git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@30431 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Torben Wilson 2000-08-17 23:53:23 +00:00
parent f81d11bc47
commit 359a10b20f
1 changed files with 31 additions and 30 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

61
language/types.xml
View file

@ -62,9 +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).
The size of an integer is platform-dependent, although a
maximum value of about 2 billion is the usual value
(that's 32 bits signed).
</para>
</sect1>
@ -78,34 +78,35 @@ $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).
The size of a floating point number is platform-dependent,
although a maximum of ~1.8e308 with a precision of roughly 14
decimal digits is a common value (that's 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>
<warning id="warn.float-precision">
<para>
It is quite usual that simple decimal fractions like
<literal>0.1</literal> or <literal>0.7</literal> cannot be
converted into their internal binary counterparts without a
little 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> as the result of the internal representation
really being something like <literal>7.9999999999...</literal>.
</para>
<para>
This is related to the fact that it is impossible to exactly
express some fractions in decimal notation with a finite number
of digits. For instance, <literal>1/3</literal> in decimal form
becomes <literal>0.3333333. . .</literal>.
</para>
<para>
So never trust floating number results to the last digit and
never compare floating point numbers for equality. If you really
need higher precision, you should use the <link
linkend="ref.bc">arbitrary precision math functions</link>
instead.
</para>
</warning>
</sect1>
<sect1 id="language.types.string">