X-Git-Url: http://nsz.repo.hu/git/?a=blobdiff_plain;f=libm%2Findex.html;h=fa908a3b8223ed96aa7fe796e839583dcca626dc;hb=d150cfff9b8023f6f8e0cd396c756c205d6a1b17;hp=abdd7f844829c334dac042ff99a52f5adf65bdad;hpb=a1c9bbca9f66a10878d905a86d6d0d99797fd77d;p=www diff --git a/libm/index.html b/libm/index.html index abdd7f8..fa908a3 100644 --- a/libm/index.html +++ b/libm/index.html @@ -146,7 +146,7 @@ m68k and m88k cpus use different ld80 than the intel ones)
If a value rounded twice the result can be different than rounding just once. @@ -162,10 +162,12 @@ results in extended precision, this only affects x87 instructions, not see2 etc) (afaik freebsd and openbsd use double precision by default)
So x = a+b may give different results depending on -the fpu setting. +the x87 fpu precision setting. (only happens in round to nearest rounding mode, but that's the most common one)
+(double rounding can happen with float vs double as well) +
C99 annex F prohibits double rounding, but that's non-normative. @@ -188,7 +190,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 +
+(a+b)==(a+b) ++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 +208,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 +
+(double)(a+b)==(double)(a+b) ++both sides are guaranteed to be in double precision when the comparision is done.
(This still does not solve the x87 double rounding @@ -252,7 +261,7 @@ different precision than at runtime). C99 actually allows most of these optimizations but they can be turned off with STDC pragmas (see 6.10.6). -Unfortunately gcc does not support these pragmas. +Unfortunately gcc does not support these pragmas.
FENV_ACCESS ON tells the compiler that the code wants to access the floating point environment (eg. set different rounding mode) @@ -300,11 +309,18 @@ in the libm code: scalbn even depends on signed int overflow.
-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 +
+x*I ++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 (an fmul instruction is generated for 0*x)
-(There were various complex constant folding issues as well). +(There were various complex constant folding issues as well in gcc).
So a+b*I cannot be used to create complex numbers, instead some double[2] manipulation should be used to