> On 3 Dec 2017, at 12:02, Antoniotti Marco <antoniotti.ma...@disco.unimib.it> > wrote: > > Hi > > I am fooling around with a problem that eventually will have to use a hash > table on “triples” of “integers” and “structures". Triples I can portably > pass to the EQUAL hash table. I cannot use an EQUALP hash table, because I > would end up wasting to much time. > > Here is the rub: my triples <N, O1, O2> need to use the “object identity” of > O1 and O2 (two structs). I could switch to an EQL hash table keyed on > (HASH-TRIPLE-KEY N O1 O2). How would you proceed (or write HASH-TRIPLE), > while staying as much portable as possible? As you well know SXHASH is > practically useless. >> >> On Dec 3, 2017, at 12:27 , Jason Cornez <jcor...@alum.mit.edu >> <mailto:jcor...@alum.mit.edu>> wrote: >> >> Add an integer slot on the structs; hash on that? -Jason > > I forgot to mention it. THAT is another thing I want to avoid because I need > to share subgraphs (DAGs). I need to hash on the “object identity”.
The thing is that there’s no conforming way to obtain the “object identity” other than the object itself, and no other conforming way to use it than to use EQ/EQL or other operators using EQL, such as EQL hash-tables. If you want to rely on implementation specific behavior, you can extract (a representation of) the object identity using print-unreadable-object. If identity is true <http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_t.htm#true>, the output from forms is followed by a space character and a representation of the object's identity, typically a storage address. cf. eg. https://gitlab.com/com-informatimago/com-informatimago/blob/master/common-lisp/cesarum/utility.lisp#L833 <https://gitlab.com/com-informatimago/com-informatimago/blob/master/common-lisp/cesarum/utility.lisp#L833> So a good conforming way to do it, is to add an integer slot to the structure, with a unique integer in it. Another way to do it, is to use the structure as a key in a EQL hash-table mapping to the unique integer (with amortized O(1) time to get the object identity). If you’re short on memory, you may store the structures in a vector, and use its index as object identity (but if you want to collect structures, it’ll leave holes, and it’s now O(n) to find the object identity). So the cheapest way is indeed to add an integer slot to the structures. Note that using sxhash doesn’t give the object identity. An implementation could very well return 42 for all the structures. So you could use it only to index buckets of structures, but you would still have to build the identifying integers in one of the above ways. Obviously, the integer “object identity” slot of your structures would be unique amongst all your identifiable structures, and would not depend on the hash-table you would store them in. -- __Pascal J. Bourguignon__
