Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!Kenny%his-phoenix-multics.arpa@BRL.ARPA From: Kenny%his-phoenix-multics.arpa@BRL.ARPA Newsgroups: net.micro.cpm Subject: Turbo Pascal--first impressions Message-ID: <16777@sri-arpa.UUCP> Date: Fri, 17-Feb-84 20:05:00 EST Article-I.D.: sri-arpa.16777 Posted: Fri Feb 17 20:05:00 1984 Date-Received: Tue, 21-Feb-84 03:51:23 EST Lines: 49 From: Kevin KennyThe problem that you're describing (where frac (1.23 * 100) isn't zero) is the usual truncation error in binary arithmetic. If they say that they'll fix it Real Soon Now, they either are lying, or mean that they intend to foul things up further; to someone who's doing numerical analysis, the result is CORRECT (if it's very close to 0 or 1; you didn't say what the result is, just what it isn't). [flame on] I am getting awfully tired of people who say that decimal arithmetic is "inherently more accurate" than binary. This claim is absolute rubbish. [blowtorch valve off again]. The problem, of course, is that there is no exact binary representation for 1.23; the expansion is a repeating string beginning 1.0011101011100001010001 with the last twenty digits repeating. The fact that 1.23 can be represented as a finite-length string in decimal leads people to claim that "decimal is more accurate." But, try representing 1/3 in either system. It doesn't go, does it? Does this say that we should all switch to the ancient Babylonian (base sixty) system, where 1/3 can be represented exactly as <00>.<20>? I don't think so. The point is, that any number can be represented to any level of precision (short of exact) in any radix. No radix can represent all numbers exactly; Georg Cantor proved that a long time ago. I concede that there is a problem in dealing with bankers and other people who expect dollars and cents to come out even. But a dollar amount isn't a floating point number at all: it's an integer number of cents! In COBOL and PL/1, there are facilities to deal with the idea that an integer might have a "decimal point" in its displayed representation. In most other languages, you just have to remember that a variable contains an amount in cents and convert it before displaying. It's not that tough. Really it isn't. The floating point implementations that "don't have this problem" use "fuzzy comparisons". What this means is that if the difference between two numbers is less than some arbitrary constant times the smaller one, they are considered equal. This keeps the bankers happy, but drives the engineers up a wall; there's an implicit loss of (real) precision to gain the (perceived) accuracy. Enough said. Just a one sentence summary: COMPARING TWO FLOATING POINT NUMBERS FOR EXACT EQUALITY IS NEARLY ALWAYS A MISTAKE, WHATEVER BASE THE MACHINE USES. /k**2