-=> Quoting Frank Cox to Rickey Parrish <=-
 FC> I was interested in the difference in the numerical results achieved,
 FC> rather than the time that it took to achieve them. -!- Msgedsq 2.2e
 Your numerical results were all perfect ;-) Or at least as
 perfect as any digital computer working in binary representation
 dealing with organisms that work in base 10 can ever be ;-) Many
 (I'd say most but some pedant would probably assault me ;-)
 exact fractional numbers in base 10 cannot in principle be
 represented exactly in base 2. Consider 0.1. a nice exact number
 in base 10. When we go to the computer we represent real values
 as a binary fraction plus an exponent. Furthermore we only are
 allowed to use a specific number of bits to represent the
 fraction. It turns out the number of bits we use affects the
 available precision of the representation but not whether or not
 we can represent the value exactly in the new base. 0.1 can
 never be exactly rendered in binary. No matter how many bits we
 have available the sum of:
 n(i) x 1/2^i where i ranges from 0 to some maximum and "n(i)" is
 either 1 or zero can never work out to precisely 0.1. Try it
 ;-)
 By allowing "I" to be very large we can get a binary value which
 is "arbitrarily close to 0.1 base 10 but we can never get a
 value equal to it ;-)
 So any computer doing arithmetic on real numbers in binary can
 never get exact theoretical values when the results are
 converted back to base 10. The original numbers used to start the
 calculation out and all intermediate results are all ever so
 slightly wrong simply because of the base conversion issue. The
 result is that the final answers are never exactly what theory
 says they should be. If you want them to be then you have to
 recast the calculation so it is done entirely in integers which
 are always exactly representable in both systems.
 The issue is much more serious than this however. This inherent
 "noise" can result in really wrong answers. A simple example
 will show how. Imagine a program which computes the result of a
 series of calculations and at some point in the calculation the
 expression contains your answer which should be 2500 exactly
 subtracted from another answer in the series which should also
 be 2500 but arrived at via a different path of calculations. In
 analysis of such a result you would "know" the answer would be
 "0" however your calculation might turn out to be:
     2500.000000123 - 2500.000000122 = 0.000000001
 From here on in you don't use 0 for the intermediate result you
 use 0.000000001 and if a subsequent step is to multiply by 10^20
 instead of getting zero (the right answer) you get a nonzero
 result very fdifferent from 0 (10^11 in fact). That's why
 writing good numerical simulation or other scientific
 calculation software turns out to be much more difficult than it
 sounds looking at the equations ;-) On a more prosaic level and
 for the same essential reason simply getting a column of
 financial dollars and cents data to add and display correctly
 turns out to be far more difficult in the general case than you
 would believe possible till you have been through it a few
 times ;-) An engineer looks at a column of 10 numbers all ending
 in "0.01" that adds to a displayed total of ".11", thinks "thats
 just rounding" and carries on but an accountant throws a major
 "hissy fit" about it ;-)
 -- Regards --
    Sid Lee (FIDO - 1:134/122,  Internet - sidlee@agt.net)
 
--- Blue Wave/Max v2.12
---------------