accumulator

[Roger Schlafly]

>> Comparing his result with Ann's, John realized that they were different.
>> There was a difference of more than 34 thousand dollars!

Both answers are wrong.  The gov't figures have only 6 significant figures,
and could be off by 5e5.  The 34e3 error is inconsequential.

An accurate accumulator is useful in some cases, but

1. How do you propose handling input uncertainties?

2. What syntax will trigger the accumulator?  Eg,

	double sum = 0;
	for (int i = 0; i < 100; ++i)
	{
		sum += a[i];
		...
	}

Won't this depend on how smart the compiler is?  On hardware?  On what
is in "..."?

3. How about

	x = a + b + c;
	...
	x = x + d + e;

If x is rounded twice, it will differ from a + b + c + d + e.  Won't
there always be sums with rounding error, no matter how smart the
compiler is?

4. If there are pennies, as in "Salary of customer $4,972.29", and
the computer is in binary, won't the answer usually be wrong anyway?

5. If there are other operations, eg multiply and square root, then
those have rounding errors.  Why are the summing errors any worse?

It seems to me that interval arithmetic address all these problems,
but that an accurate accumulator only handles certain contrived cases.
There is hardware (IEEE) and high-level languages (C++) that make
interval arithmetic feasible.  Why don't John and Ann use that?

--------------------------------------------------------------------------
| Roger Schlafly * voice phone or fax: 408-476-3550 * BBS: 408-476-1055  |
| US Mail: Real Software, PO Box 1680, Soquel, CA 95073 USA              |
| MCI: RSchlafly * CIS: 76646,323 * GEnie: R.Schlafly * Prodigy: TTDX08A |
| Internet: 76646.323aCompuServe.com or 0002956602aMciMail.com           |
--------------------------------------------------------------------------