Ascending & descending for loops give different answer in summation - why?

[falloutphil]

Hi,

I'm at a loss to explain an issue I'm seeing below. It's a simple enough peice of C++, just sum all the values of 1/n from n=1 to n=10000. Easy, eh? The problem I have is explaining why when looping for the large to small bound i.e. 10000 down to 1 do I *always* get a slightly larger result than if I loop from 1 to 10000?

My gut instinct and some further testing tells me this is a rounding problem - for example if I use 'long double' then no rounding error is seen in the first 20dp, but given the same range in both loops, I can't explain why the decrementing loop comes out larger for any large-ish n?

I'd be eternally grateful if someone could explain this in detail or point me to a good link?

Cheers,

Phil.

Program output - GCC 4.0.1:
Small to large: 10.78760603604437307
Large to small: 10.787606036044381952

#include <iostream>
#include <iomanip>

int main(int argc, char *argv[])
{
  double result=1.;
  std::cout << std::setprecision(20) << "\n:";
  for(double i=1.; i<=10000.; ++i)
    {
      //std::cout << "\n" << i;
      result += 1./i;
    }
  std::cout << "\n\nSmall to large: " << result;
  result = 1.;
  for(double i=10000.; i>=1.; --i)
    {
      //std::cout << "\n" << i;
      result += 1./i;
    }
  std::cout << "\nLarge to small: " << result << "\n\n";
  return 0;
}

[Narue]

>I'd be eternally grateful if someone could explain this in detail or point me to a good link?
Here's a good link , but the short answer is that due to floating-point imprecision, simply changing the order of arithmetic operations can affect the accuracy of the result.

[Jishnu]

Here's another article that might be of help.

[falloutphil]

Thanks for the links all! I'll have a read through them.