On 04/05/2015 07:37 AM, Bill Page wrote: > After reviewing all of the discussion in this thread concerning > XHashTable, I find that I now agree with Ralf's original response. > Perhaps it is not a good design decision to pass a custom equality > when creating an XHashTable.
Oh... and I've already started trying to generalize XHashTable. :-( ;-) > In fact, I would go further and claim that this also applies to the > passing of a custom hash function which is permitted in the current > implementation of XHashTable. This "extra" feature of XHashTable > should be removed. Yes and no. However, even though I don't yet have a particular use case, I could imagine that for certain situations it makes sense to create a hash function which is tailored to the problem at hand. For example, suppose you want create a hash table where the keys are strings that alll start with the string "http://.../"; where the ... stands for a rather long URL. Of course, one can cut that part of the string, but one could also use another hash function. More importantly, in some cases the default hash function of the domain would not yield equal distribution of the keys, since only a specific part of the elements will ever appear as keys. Admittedly, creating such a specific hash function would be an art, but that is the reason for allowing a hash function as a parameter to table. However, if Waldek agrees, I see currently no big problem in dropping this "extra feature". > It seemed overly ridged at first to insist on enforcing the contract > between the = and hash functions at the category level because this > forces the creation of a new domain in the case I had in mind, i.e. > using XHashTable in Kernel instead of SortedCache. But now I begin > to see this as the best option. Perhaps what I want is something we > might call "InnerKernel" which exports a much simpler (cheaper) kind > of equality and an associated hash function. Then I would use > InnerKernel together with XHashTable in the Kernel domain itself to > implement a more "mathematical" equality. And now I also think Ralf > and Waldek were right to claim that really this has more to do with > representation than I was initially willing to admit. Yes, that's what I said about creating ExpressionRep. Well, you want InnerKernel, but that goes probably in the same direction. Caching the representation of two (differnently looking) kernels that are mathematically equal, can be done with XHashTable if = means equality of representation. That caches a few more kernels, but otherwise would be sound wrt. XHashTable's requirements. Would be somehow nices to "collaps"/"replace" two (mathematically) equal kernels by a "dominant" one, if the two are recognized as being equal. Bill, maybe you try to come up with a suggestion that introduces InnerKernel. Ralf -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
