<div dir="ltr">Hi Massimiliano,<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 27, 2015 at 11:38 PM, Massimiliano Ghilardi <span dir="ltr"><<a href="mailto:massimiliano.ghilardi+abcl@gmail.com" target="_blank">massimiliano.ghilardi+abcl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 01/26/15 07:40, Mark Evenson wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 25 Jan 2015, at 20:19, Massimiliano Ghilardi <<a href="mailto:massimiliano.ghilardi%2Babcl@gmail.com" target="_blank">massimiliano.ghilardi+abcl@<u></u>gmail.com</a>> wrote:<br>
<br>
Massimiliano Ghilardi<br>
</blockquote>
<br>
Nice fix.  Promoted as [14749][].<br>
<br>
Need to release a abcl-1.3.2 real soon now…<br>
<br>
[14749]: <a href="http://abcl.org/trac/changeset/14749" target="_blank">http://abcl.org/trac/<u></u>changeset/14749</a><br>
</blockquote>
<br></span>
Thanks Mark.<br>
<br>
My patch stops EQUALP from signaling errors on "impossible" bignum-to-float comparisons, i.e. between floats and bignums larger than the biggest representable floats.<br>
<br>
Anyway, it does not fix an existing bug for "possible" comparisons, i.e. between floats and bignums in the range representable by floats.<br>
<br>
The usual CLHS<br>
file:///home/max/SW/lisp/docs-<u></u>lisp/HyperSpec/Body/f_equalp.<u></u>htm#equalp<br>
tells that EQUALP on two numbers is the same as =.<br>
<br>
There are cases where ABCL does not follow it:<br>
<br>
CL-USER> (= most-positive-single-float 340282346638528859811704183484<u></u>516925440)<br>
T<br>
<br>
CL-USER> (equalp most-positive-single-float 340282346638528859811704183484<u></u>516925440)<br>
T ;; correct :)<br>
<br>
CL-USER> (= most-positive-single-float 340282346638528859811704183484<u></u>516925439)<br>
NIL<br>
<br>
EQUALP behaves differently from =, because (EQUALP bignum float) converts the bignum to float, losing precision:<br>
<br>
CL-USER> (equalp most-positive-single-float 340282346638528859811704183484<u></u>516925439)<br>
T ;; incorrect :(<br>
<br>
<br>
<br>
Digging more reveals further inconsistencies...<br>
<br>
CL-USER> (= 1.0 #C(1.0 0.0))<br>
T<br>
<br>
CL-USER> (equalp 1.0 #C(1.0 0.0))<br>
NIL ;; again :(<br>
<br>
The fix is conceptually simple: for all the number tower, EQUALP must use the same algorithm as =, with the only difference that it must never throw.<br>
<br>
I am not sure which Java method implements the function =<br>
so I don't dare yet to write a patch. Maybe isEqualTo() ?<br></blockquote><div><br></div><div>Right on the mark! See Primitives.java#L1235 and compiler-pass2.lisp:p2-numeric-comparison ; the former for interpreted code, the latter for compiled code.</div><div><br></div><div>Thanks for taking the time to submit patches!</div><div><br></div></div>-- <br><div class="gmail_signature"><div dir="ltr">Bye,<div><br></div><div>Erik.</div><div><br></div><div><a href="http://efficito.com/" target="_blank">http://efficito.com</a> -- Hosted accounting and ERP.</div><div>Robust and Flexible. No vendor lock-in.</div></div></div>
</div></div>