When is equality NOT equality?

[NashGussetts]

I have the following lines in a lager routine I'm debugging:

      (If (<= (/ mezzarea suitearea) 0.1)         
         .... do stuff

mezzarea is EXACTLY one tenth of suitearea and they are both reals, so I'm asking is 0.1 <= 0.1, yet the line returns nil no matter what.

Doubt me? See attached jpeg from the console window.

[Kent1Cooper · Accepted solution]

---

@NashGussetts wrote:

I have the following lines in a lager routine I'm debugging:

      (If (<= (/ mezzarea suitearea) 0.1)         
         .... do stuff

mezzarea is EXACTLY one tenth of suitearea and they are both reals, so I'm asking is 0.1 <= 0.1, yet the line returns nil no matter what.

.... 

---

It's probably in some far-in decimal place beyond what your display rounds things to.  Try forcing it to show you lots of decimal places by comparing:

(rtos mezzarea 2 16)

to

(rtos (/ suitearea 10) 2 16)

to see whether they're really as equal as you think.  If not, you can overcome that kind of calculation fuzziness by checking for equality with a tiny fuzz factor:

(If

  (or

    (< (/ mezzarea suitearea) 0.1)

    (equal (/ mezzarea suitearea) 0.1 1e-6)

  ); or

  (...then do stuff...)

); if

You can use a different number of decimal places [replace the 6 above with something else].

[NashGussetts]

Thanks, I had a feeling it was a fuzz problem but when I checked the help on <= it was silent on how/whether fuzz was a 'factor'

Writing this stuff is hard enough without the machine telling you 0.1/=0.1

[Kent1Cooper]

---

@NashGussetts wrote:

Thanks, I had a feeling it was a fuzz problem but when I checked the help on <= it was silent on how/whether fuzz was a 'factor'

Writing this stuff is hard enough without the machine telling you 0.1/=0.1

---

It may be that among AutoLISP functions, only (equal) can account for fuzz -- I'm not sure that's the only one.  [PEDIT in the Multiple/Join mode has an option for it.]  Of couse, it's not really telling you that 0.1 doesn't equal 0.1, but that one number that displays as 0.1 may not be the same, all the way down to the precision with which it works in the background, as another number that displays as 0.1.  If you set two variables to 0.1 explicitly, they will be equal -- the problem comes in when a number is the result of some calculation, such as of the area of, say, a Polyline perimeter, especially if it doesn't have nice clean round-number-value vertex coordinates and orthogonal edges.

[Lee_Mac]

Kent1Cooper wrote:

(If

  (or

    (< (/ mezzarea suitearea) 0.1)

    (equal (/ mezzarea suitearea) 0.1 1e-6)

  ); or

  (...then do stuff...)

); if

You could also simply add the tolerance to the upper bound for the <= expression, e.g.:

(if (<= (/ mezzarea suitearea) (+ 0.1 1e-6))
    ... do stuff ...
)

[BeKirra]

Yes, AutoLispers have to deal with such issues.

This may be off the topic but FYI:

Supposedly Tan45(degrees) = 1.0 exactly but

(rtos (sin (/ pi 4)) 2 16) = "0.7071067811865475", while
(rtos (cos (/ pi 4)) 2 16) = "0.7071067811865476".

As the result, TAN45(degrees) = "0.9999999999999998".

Note: TAN(angle) = (SIN(angle)) / (COS(angle))

And it may explain why AutoLisp doesn't offer a "TAN" function.

There are something behind the AutoLisp and may relate to the processor.

[Kent1Cooper]

---

@BeKirra wrote:

Yes, AutoLispers have to deal with such issues.

This may be off the topic but FYI:

Supposedly Tan45(degrees) = 1.0 exactly but

(rtos (sin (/ pi 4)) 2 16) = "0.7071067811865475", while
(rtos (cos (/ pi 4)) 2 16) = "0.7071067811865476".

As the result, TAN45(degrees) = "0.9999999999999998".

Note: TAN(angle) = (SIN(angle)) / (COS(angle))

And it may explain why AutoLisp doesn't offer a "TAN" function.

There are something behind the AutoLisp and may relate to the processor.

---

---

@BeKirra wrote:

....

Supposedly Tan45(degrees) = 1.0 exactly but

(rtos (sin (/ pi 4)) 2 16) = "0.7071067811865475", while
(rtos (cos (/ pi 4)) 2 16) = "0.7071067811865476".

As the result, TAN45(degrees) = "0.9999999999999998".

....

---

That is probably not just a processing-precision issue, but as much a result of the fact that it works in radians rather than degrees.  45 is an exact number of degrees, but (/ pi 4) is not an exact number of radians, since pi is irrational.  The system can work with only a certain number of decimal places, so the value is necessarily rounded off.

[NashGussetts]

Yeah, I remember this. Would be nice if VLISP gave you more ways to acount for the fuzz factor and if the IDE would tell you the actual value of a real.

Whose side are they on? ; )

[Kent1Cooper]

---

@NashGussetts wrote:

Yeah, I remember this. Would be nice if VLISP gave you more ways to acount for the fuzz factor and if the IDE would tell you the actual value of a real.

Whose side are they on? ; )

---

The side of reality, I'm afraid.  After all, if you were asked to tell the "actual value" of, for instance, (/ pi 4), what would you say?  Pi has been calculated out to several million [or is it billion?] decimal places....

[And sorry about the double quoting in my previous message -- apparently the quote button registered twice, and the first one scrolled up where I didn't see it.  I only meant to include the edited-down second quote.]