Matthew Heaney wrote: > > In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > >As for when it makes sense to compare floating-point values for equality, > >that is a matter for the programmer to understand. Floating-point arithmetic > >on modern IEEE machines is not some kind of approximate hocus-pocus, it > >is a well defined arithmetic systenm, with well defined, well behaved > >results, in which equality has a perfectly reasonable meaning. > > OK, so if do this > > declare > m1, m2 : slope; > begin > if m1 = m2 then > > and I'm using IEEE floating point types (I'm on a SUN box), can I assume > that the lines are parallel? > > -------------------------------------------------------------------- > Matthew Heaney > Software Development Consultant > > (818) 985-1271 The slopes might compare equal when they are, in reality, different. Just to be fair, the slopes also might compare unequal when they are, in reality, the same. The following examples show this in decimal; but the general problems exists in binary and all other bases, too. Suppose you compute the slope of the line going through the origin (0,0) and the point (1,2). The slope is simply 2. But, suppose the two points are the origin (0,0) and the point (1, 2.00000...0001). To machine accuracy, the second point (given enough implied zeroes) is indistinguishable from the first. The distinct lines will appear to be not just parallel, but also coincident. Now try specifiying the first line, above, by two other points, such as (1/3, 2/3) and (2/3, 4/3). To machine accuracy, these are (0.333...333,0.666...667) and (0.666...667,1.333...333). Computing the slope will give (0.666...6666/0.333...334) - watch the final digit carefully - which is slightly less than a slope of 2, and not going through the origin. A single line, here, appears to be distinct lines. In general, depending on the exact two points and the effects of rounding on all the numbers, you can get any results (e.g., the slope is less than 2, equal to 2, or greater than 2). The slopes are all approximately equal, but not idential. I don�t know of any �easy answers� to floating point accuracy. I use tests for exact equality when appropriate - based on understanding of whatever problem I�m trying to solve, not rote translation of some equation or procedure from a pure-math (i.e., infinite precision) to a practical program. Exact equality is often not appropriate, at which point some combination of absolute difference and relative difference is generally effective - again, with the numeric tolerances based on understanding of the problem being solved. I�ve even been able to use "... even if off by a factor of a few billion, ..." - which is a humungous percentage error. Lynn Killingbeck