LOGO-L> RE: Numeric Precision in Logo
Author Message 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/

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

Fri, 12 May 2000 03:00:00 GMT  LOGO-L> RE: Numeric Precision in Logo

Quote:

>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.

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,

Sat, 13 May 2000 03:00:00 GMT  LOGO-L> RE: Numeric Precision in Logo

[snip]

Quote:

> 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.

[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

Sun, 14 May 2000 03:00:00 GMT

 Page 1 of 1 [ 4 post ]

Relevant Pages