[Armedbear-devel] EQUALP raises type-error comparing large bignums to floats (patch attached)

Massimiliano Ghilardi massimiliano.ghilardi at gmail.com
Tue Jan 27 21:40:04 UTC 2015

On 01/26/15 07:40, Mark Evenson wrote:
>> On 25 Jan 2015, at 20:19, Massimiliano Ghilardi <massimiliano.ghilardi+abcl at gmail.com> wrote:
>> Massimiliano Ghilardi
> Nice fix.  Promoted as [14749][].
> Need to release a abcl-1.3.2 real soon now…
> [14749]: http://abcl.org/trac/changeset/14749

Thanks Mark.

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.

Anyway, it does not fix an existing bug for "possible" comparisons, i.e. 
between floats and bignums in the range representable by floats.

The usual CLHS
tells that EQUALP on two numbers is the same as =.

There are cases where ABCL does not follow it:

CL-USER> (= most-positive-single-float 

CL-USER> (equalp most-positive-single-float 
T ;; correct :)

CL-USER> (= most-positive-single-float 

EQUALP behaves differently from =, because (EQUALP bignum float) 
converts the bignum to float, losing precision:

CL-USER> (equalp most-positive-single-float 
T ;; incorrect :(

Digging more reveals further inconsistencies...

CL-USER> (= 1.0 #C(1.0 0.0))

CL-USER> (equalp 1.0 #C(1.0 0.0))
NIL ;; again :(

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 

I am not sure which Java method implements the function =
so I don't dare yet to write a patch. Maybe isEqualTo() ?


Massimiliano Ghilardi

More information about the armedbear-devel mailing list