Re: CCL:ifc -O0 failure

On Mon, 9 Jun 2003, caroline taylor wrote:
 > -O0:    6.710886E+07  (21.960u 0.020s 0:22.19 99.0%)
 > -O1:    1.718282E+08  (17.560u 0.010s 0:17.76 98.9%)
 > The 0 level optimization is clearly inconsistent, and far larger than
 > round off. This has been checked on multiple machines (all linux).
 >
 > Has anyone run into this before? Is there a known problem with this level,
 > or is something else going on?
 Caroline,
 There is nothing wrong with ifc in this case - your program is badly
 broken, and should not be relied upon to produce -any- definite
 answer. You are trying to accumulate numbers, which deviate from
 one in the 7-th decimal digit. However, you chose to use a type
 (REAL), which is only accurate to 6-7 decimal digits. Obviously,
 you should not expect to get any significant digits in the result.
 With optimizations turned on, ifc carries the accumulation at
 higher 80-bit precision (which is arguably allowed by the standard),
 which -accidentally- leads to a result close to the mathematically
 exact value.
 If you change your SUM to DOUBLE PRECISION, you will get the answer of
 171828183.705001 as an answer for ifc -O0 - which is reasonably close
 to the formal result of 171828183.705045439197452888531281012...
 Incidentally, if you try to use this loop for timing purposes, this
 is not necessarily a good idea - a sufficiently smart compiler
 could realise that the exact result is given by:
  (E - 1) E**(1/100000000)
  ------------------------
   E**(1/100000000) - 1
 and completely eliminate the loop.
 Serguei