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)
- 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).
@@ -78,34 +78,35 @@ $a = 0x12; # hexadecimal number (equivalent to 18 decimal)
$a = 1.234; $a = 1.2e3;
- 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).
-
-
- 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 floor((0.1+0.7)*10)
- will usualy return 7 instead of the expexted
- 8 as the result of the inner expression
- really something like 7.9999999999....
-
-
- This is similar to the impossibility of writing down the result
- of 1/3 exactly in decimal form with a limit
- numer of digits as it is 0.3333333....
-
-
- 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
- arbitrary precision math functions
- instead.
-
-
+
+
+ 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 loss of precision. This can lead to confusing results: for
+ example, floor((0.1+0.7)*10) will usually
+ return 7 instead of the expected
+ 8 as the result of the internal representation
+ really being something like 7.9999999999....
+
+
+ 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, 1/3 in decimal form
+ becomes 0.3333333. . ..
+
+
+ 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 arbitrary precision math functions
+ instead.
+
+