From 359a10b20f1bce6281d657677cecc1a5e382d96d Mon Sep 17 00:00:00 2001
From: Torben Wilson <torben@php.net>
Date: Thu, 17 Aug 2000 23:53:23 +0000
Subject: [PATCH] Small typo/clarification/indentation fixes.

git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@30431 c90b9560-bf6c-de11-be94-00142212c4b1
---
 language/types.xml | 61 +++++++++++++++++++++++-----------------------
 1 file changed, 31 insertions(+), 30 deletions(-)

diff --git a/language/types.xml b/language/types.xml
index c5ccb45c7a..40b6fcfeab 100644
--- a/language/types.xml
+++ b/language/types.xml
@@ -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">