[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com>*Subject*: EQUAL, and hash tables, and value/object distinctions*From*: Barry Margolin <barmar@Think.COM>*Date*: Fri, 1 Jul 88 15:15 EDT*Cc*: jrose@sun.com, edsel!jonl@labrea.stanford.edu, goldman@vaxa.isi.edu, common-lisp@sail.stanford.edu*In-reply-to*: <19880630203650.3.GREENWALD@SWALLOW.SCRC.Symbolics.COM>

Date: Thu, 30 Jun 88 16:36 EDT From: Michael Greenwald <Greenwald@stony-brook.scrc.symbolics.com> For example, one cannot construct a hash-function for #'= unless you limit the valid keys to not include both a floating point number and two integers that both coerce to that same float. (i.e. (let* ((a (expt 2 56)) (b (1+ a)) (c (float a))) (values (= a b) (= a c) (= b c))) => NIL T T ) Actually, it's not that difficult to construct such a hash function. All it has to do is coerce its argument before hashing, e.g. (defun =-hash (number) (let ((real (realpart number)) (imag (imagpart number))) (setq number (complex (coerce real 'long-float) (coerce imag 'long-float)))) <compute the hash>) I admit that this isn't a great hash function if you expect your keys to include many bignums that are near each other. But it is guaranteed to be a correct hash (assuming <compute the hash> is well behaved). barmar

**Follow-Ups**:**EQUAL, and hash tables, and value/object distinctions***From:*Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>

**References**:**EQUAL, and hash tables, and value/object distinctions***From:*Michael Greenwald <Greenwald@STONY-BROOK.SCRC.Symbolics.COM>

- Prev by Date:
**Re: Issue: STACK-LET (Version 1)** - Next by Date:
**dynamic extent lisp objects** - Previous by thread:
**EQUAL, and hash tables, and value/object distinctions** - Next by thread:
**EQUAL, and hash tables, and value/object distinctions** - Index(es):