
LOGO-L> RE: Numeric Precision in Logo
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.
Quote:
> I recently wrote a Molecular dynamics simulation in MSW LOGO and
> ran into a problem in how LOGO handles floating points numbers. One
> of the calculations in the program was
> make "time sum :delta_t :time
> Adding a delta_t of 0.02 to a time of 0 1640 times gave me a
> value of time that was 32.7799999999995 , that is a small error but
> an error none the less. The problem is that with more iterations of the
> program the error grows exponential and after a hour or so
> of running the simulations the values walk straight into the
> ether.
> This poses a severe limitations on the type
> and scale of models that can be constructed in LOGO. I realize that
> I'm probably pushing LOGO beyond it intended domain but you except
> the correct answer from a computer
> As a test of this error, I wrote the following program
> to atest
> (local "times "number)
> make "number 0
> for [j 1 6 1 ]~
> [ make "times power 10 :j
> type [times -> ]
> print :times
> for[i 1 :times 1]~
> [make "number sum :number 0.01]
> type [result -> ]
> print :number
> make "number 0
> ]
> end
> Running the program produces the same wrong results on two different
> machines (one WIN95, the other WINNT).
> ********************************************************************
> Tony Gauvin (207) 581-1367
> 109 Neville Hall
> Dept of Computer Science
> University of Maine
> Orono Me 04469
> http://www.*-*-*.com/
---------------------------------------------------------------