Anthony,

Errors as the one you described are inherent to the representation of
decimal numbers in the so-called floating point format (which is usually in
the exponent/mantissa binary representation). I did a sum of 5,000 cells
containing 0.02 in Excel 7.0 and the result was 99.9999999999972, not 100.
Also in Corel Quattro Pro the result was 99.9999999999973. (By the way,
your result looks more like adding 0.02 1639 times rather than 1640.)

Bottomline, this is not a Logo-only problem, although it might be corrected
by a non-binary implementation of floating-point numbers (binary is the
native format built into C, C++ et al). I remember using 100+ decimal
positions in Apple Logo sometime.

In the meantime, you must have to take several precautions, because
rounding errors do tend to build up. In your example, you could switch to
milliseconds, and thus add "20" instead of "0.020" and then dividing the
result by 1000. Also, when adding decimal numbers always check for the sum
not "equal to" a given target, but "in the vicinity" of the target (like "A
in [B-delta,B+delta]", where "delta" is an appropriately small number).
This may turn cumbersome, but it is a fact of life. You may want to consult
a book on numerical analysis if things get difficult.

---------------------------------------------------------------

   Just a minor point I'd like to make here.  While the programming
langugage can use any representation it wants for floating point
numbers, by far the most common is a binary format set by the IEEE
754 standard.  This is because this standard is implemented in hardware
on most current day processors, and hence is the most efficent.

Enjoy,

[snip]

[snip]

yes the problem lies in the floating point numbering system.  Binary
fractions are just not that good for representing decimal numbers.  For
example: 0.02 is stored in binary as (if I haven't made any arithmetic
mistakes) 0.0000010100011110101... with no end in sight.  (it may repeat
forever.)  For those not familiar with a binary rational, the above
number is 1/2^6+1/2^8+1/2^12+1/2^13+1/2^14+1/2^15+1/2^17+1/2^19 or
something.  The more bits we use, the more accurate it gets.
In decimal: 2/10^2.
So some simple rationals are not well encoded by binary.  BCD or
binary-coded decimal is one answer.  I'm not sure the exact format, but
it takes the stream of numbers, maybe using 4 bits per digit, and
encodes the number as it really appears in decimal.

Another method would be to employ what's known as floating-slash
aproximation.  This is where we use two integers (which can be
represented exactly in binary) and use them to store a numerator and
denominator.  This, by my testing, is more accurate than floating point
within the same bit-size.  I.E. 64-bit.  It also allows *very* accurate
representation of small rational numbers.  Eg. .3333333 can be
represented by 3333333/10000000.  If that is too large of a number (ie
it's larger than we have storage room for), we can reduce it to the
approximation of 1/3.  That is very close to .3333333.  Anyway.  I can
give more details upon request.

Michael Torrie