*Post by Paul G*I'm using GNU CLISP 2.48. I've caught LISP making a pretty grievous

math error, and I don't know if it's a bug or if there's another

explanation.

(+ 0.2 0.4 0.2 0.2 9.8 15.4 1.2 5.4)

which converts each of those decimal-digit expressions into

floating-point binary approximations. In particular not one of

those eight values you entered can be expresssed exactly in binary.

(If you don't believe me, try to find an exact binary value that

equals any one of those, and report which exact binary value you

claim exactly equals which of the decimal values there.)

Then seven floating-point-approximate additions are done before

yielding the grand total, each of those possibly causign additional

roundoff errors. Finally the binary result is converted back to

decimal notation, with additional conversion error, to print the

result. So that's a total of nine (9) times you absolutely cannot

get the correct result so some roundoff *must* occur, and seven (7)

times you might also get roundoff error. Only an idiot would expect

the final result to print exactly how it'd be if you did all the

arithmetic by hand using decimal notation.

Given all the points of definite conversion approximation or

addition roundoff error, that's a pretty good result.

*Post by Paul G*Obviously this answer is off by .000003.

That's a pretty small amount of conversion+roundoff error, given

all those operations you asked it to do, all those errors you

allowed to accumulate.

*Post by Paul G*Could somebody explain to me why this is,

Why do I need to explain it to you? Don't you have the slighest

concept of decimal and binary notational systems, and the wisdom to

know that values in one system generally cannot be expressed

exactly in the other system, and indeed specifically that *none* of

the eight input values you gave above can be expressed exactly in

binary?

*Post by Paul G*and if there's a way to add these numbers correctly using CLISP?

Sure. Write a decimal-arithmetic package, which will be several

orders of magnitude slower than machine floating-point arithmetic,

but give you exact answers so long as you only add subtract and

multiply (never divide). But why would anybody waste their time

doing that?

Alternately, write an interval-arithmetic pagkage. That will give

you **correct** upper and lower bounds on the result. It won't tell

you the exact answer, but it'll tell you a narrow range in which

the exact answer lies, and that answer-interval will be absolutely

correct, and that answer-interval will also give you an upper bound

on the amount of error between the exactly-correct answer and the

midpoint of the answer-interval. With proper interface to IEEE

rounding modes, it will be nearly as efficient as ordinary

floating-point arithmetic. Or without such interface, doing the

arithmetic using binary integers with liberal use of FLOOR and

CEILING, it'll be considerably slower than floating-point, but

still much faster than decimal arithmetic.

Ideally you can write a lazy-evaluation continuation-style interval

arithmetic package, whereby it first calculates a crude set of

bounds, then any time later you can ask it to extend that work to

generate more and more accurate bounds. I started work on such a

system several years ago, but nobody show interest, nobody offered

to pay me for my work, but if you offer to pay me for what I did

already and pay me to finish the work, I'm available. For some

demos of what I was working on back then, see:

http://www.rawbw.com/~rem/IntAri/

Bottom line: You haven't caught LISP making any math error, but

I've caught you making a pretty grievous error in understanding

what exactly you asked Lisp to calculate for you.