Discussion
@screwlisp
This guy is doing a lot of interesting work on hashing *numbers* in Common Lisp (are you in fact interested in random people doing random CL work, or should I stop bugging you about such?):
https://turtleware.eu/posts/Heavenly-delights-of-hashing-numbers-under-EQUALP.html
@vnikolov @screwlisp @dougmerritt
if you read the linked post, you will find a hint at the answer.
(float x) may change the value when rounding is required. A float and a ratio can be = (hence equalp) when the ratio is dyadic, that is its denominator is a power of two. That's implicit from how binary floats are defined.
In other words CL is mathematically precise, not "drawing a line".
«CL is mathematically precise»
And here, too, is where intent also comes in.
In contexts like the present one, the choice of a precise definition of ”mathematically precise” is also a matter of intent.
For example, I can imagine an intent to replace automatically #C(17.17 0.0) with 17.17, which would match the behavior of `=’ and `equalp’.
(With Common Lisp, one would have to do this manually, of course, which can be cumbersome.)
And I don't think that ignoring letter case is “culturally consistent” with distinguishing between 1717/100 and 17.17, but again, your intended mileage may vary.
Also, note that
(and (realp x) (equalp x y))
does not imply
(realp y)
(ditto for `=’).
There are other more interesting cases in wider design space, like having a complex number with one component a floating-point number and the other a rational number.
One very famous case for this is
(/ (log -1) (sqrt -1))
(besides computer algebra systems, this requires some special casing, but arguably, acceptably little).
While `equalp’ can indeed be useful, sometimes very useful, using it successfully requires much more care than using `equal’.
The distinction between `eq’ and `eql’ is rather different in this respect, because `eql’ insists (1) on the types being the same and (2) on immutability for two things that are not `eq’.
Thus using `eql’ successfully is much more straightforward than `equalp'.
Unlike the other three, the latter's definition is not really straightforward, more an idiosyncratic combination of trade-offs and historical reasons.
And it is by far not the only workable extension of `equal’.
@vnikolov @screwlisp @dougmerritt
I'll put it this way
(= 17/100 0.17) ; -> T
would be incorrect for binary floats, mathematically speaking, so having cl return true here would be wrong.
I agree that some things are the matter of arbitrary decision and/or a performance tradeoff (float type is a performance tradeoff btw, so are fixed size integers without bignums), but this is not one of these.
