>> Ah, before I forget. XHashTable in my opinion is not going to replace >> HashTable, but rather Table. (Not at the moment, of course, but that >> would be my plan.)
> We need to implement hash functions first Yes, I see the problem with good hash functions, but I think good hash functions are orthogonal to providing a good hash table implementation. OK, but if you mean to replace AssociationList, that's of cource another issue. Do you see for the meantime any chance to recognize a good hash function from a bad one? I mean, before we started there was a default implementation of hash(x)=0 in SetCategory. Maybe we could rather define a default hash==badHash with a global function (maybe lisp) badHash and in Table try to test whether hash$Key = badHash (pointer comparison of where the function object is stored). If it is still badHash, then AssociationList would be used otherwise XHashTable could jump in. Anyway, defining a hash for a general expression is probably impossible if equality of the underlying domain is used. But what is Maple doing when one adds "option remember". In fact, to implement a cache, it's irrelevant whether hash(k1)=hash(k2) for k1=k2 where k1 and k2 have different underlying representation. It just means storing more entries in the table and of course some related consequences. But even with a bad (but reasonably well distributing) hashing routine (i.e. not a mathematical function), a true hash table instead of an association list could have some advantages. Probably depends on the user's needs. In general I would assume that the user knows when the hasing routine is bad for the respective key domain. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To post to this group, send email to fricas-devel@googlegroups.com. To unsubscribe from this group, send email to fricas-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/fricas-devel?hl=en.
