On 5 April 2015 at 05:24, Ralf Hemmecke <[email protected]> wrote: > 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. :-( ;-) >
No problem. I do not feel strongly on this issue. If you are convinced that generalization is a good idea, by all means continue. My conclusion however was that Waldek was right to say initially that this is not how it is or should be done in FriCAS/Axiom. In general I think the fact that sometimes things you think you want to do in FriCAS turn out to be quite hard is because for the most part there is only one "right way" to do things and the problem is to find this one right way. It seems to me that this is true by design. I recall at least one paper that referred to this philosophy as being "Correct by Design" rather than trying to prove that some piece of code is correct after the fact. >> 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. Of course this might be true for "certain situations". But this is also just as true for the function that represents equality. In fact it was just such a situation that motivated me to propose this extension to XHashTable. Since you obviously felt this way about the hash function it came as a shock to me that you did not immediately support this for same sort of thing for equality. > 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. > Sure, but my response here could be exactly the same as your original response to me concerning equality: Your example suggests that you are using the wrong representation. If the strings all start with "http;// ... /" then maybe you should first abstract that part away and implement a "URL" domain that stores only the variable part of the url. > 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. And for some reason you do not think this is possible with equality? > > However, if Waldek agrees, I see currently no big problem in dropping > this "extra feature". > Well, I think the motivation should come from a design philosophy rather than simple expediency. >> 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. Yes, exactly 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. If you mean caches a few more kernels than currently cached using SortedCache then yes, but I think that is unavoidable. The point is that I want to use XHashTable to *define* equality in Kernel. Obviously I can't do that if XHashTable depends on equality already being defined in Kernel. CachableSet and SortedCache expects the equivalent of an uncached equality function to be passed as part of the insertion operator (enterInCache). That is more or less what I had in mind when I proposed a similar extension to XHashTable. But now I think the basic design of Kernel is flawed. > > Would be somehow nices to "collaps"/"replace" two (mathematically) equal > kernels by a "dominant" one, if the two are recognized as being equal. > Well, um that is exactly the content of my algorithm and patch I have been discussing with Waldek ... > Bill, maybe you try to come up with a suggestion that introduces > InnerKernel. ??? Yes, maybe I can ... -- 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.
