libm: typesetting fixes
authornsz <nsz@port70.net>
Mon, 27 Feb 2012 20:42:03 +0000 (21:42 +0100)
committernsz <nsz@port70.net>
Mon, 27 Feb 2012 20:42:03 +0000 (21:42 +0100)
libm/index.html

index abdd7f8..5832554 100644 (file)
@@ -188,7 +188,11 @@ C does not require consistent evaluation
 precision: the compiler may store intermediate
 results and round them to double while keep
 other parts in higher precision.
-So (a+b)==(a+b) may be false when the two sides
+So
+<pre>
+(a+b)==(a+b)
+</pre>
+may be false when the two sides
 are kept in different precision.
 (This is not an x87 specific problem, it matters whenever there
 is a higher precision fp type than the currently used one.
@@ -202,8 +206,11 @@ C99 has a way to control this (see
 when a result is stored in a variable or a
 type cast is used, then it is guaranteed that
 the precision is appropriate to that type.
-So in (double)(a+b)==(double)(a+b) both
-sides are guaranteed to be in double precision
+So in
+<pre>
+(double)(a+b)==(double)(a+b)
+</pre>
+both sides are guaranteed to be in double precision
 when the comparision is done.
 <p>
 (This still does not solve the x87 double rounding
@@ -300,11 +307,18 @@ in the libm code: scalbn even depends on signed int overflow.
 
 <li>Complex arithmetics
 <p>
-With gcc x*I turns into (x+0*I)*(0+I) = 0*x + x*I,
-so if x=inf then the result is nan+inf*I instead of inf*I
+gcc turns
+<pre>
+x*I
+</pre>
+into
+<pre>
+(x+0*I)*(0+I) = 0*x + x*I
+</pre>
+So if x=inf then the result is nan+inf*I instead of inf*I
 (an fmul instruction is generated for 0*x)
 <p>
-(There were various complex constant folding issues as well).
+(There were various complex constant folding issues as well in gcc).
 <p>
 So a+b*I cannot be used to create complex numbers,
 instead some double[2] manipulation should be used to