On 24 March 2015 at 10:10, Ralf Hemmecke <[email protected]> wrote: > On 03/24/2015 02:35 PM, Waldek Hebisch wrote: >> I admit that current situation where at category level we claim >> there here is hash function, but a lot of domains lack implementaion >> is unsatisfactry. But it is not clear what to do. We could >> introduce new category, say 'Hashable' and make sure that >> domains which export 'Hashable' also implement 'hash'. > > My first reaction to this is, yes. There should be Hashable. That would > be much better than putting it into SetCategory. And... it sounds like a > pretty easy modification. And it would remove some unusable > "unimplemented" functions like claiming a hashfunction for Expression > (i.e. some unsoundness).
I do not think that it is unsound to claim a hashfunction for Expression. What is unsound is to claim that a hashfunction for Expression must be related to the definition of = in Expression. Or rather, as I said in my reply to Waldek: For hashing we need to know when two things are equal "as what" i.e. in what sense. Two expression can be equal in a mathematical sense or only in a syntactic sense. I proposed that hashing should therefore be connected with whether or not a domain is 'Comparable'. > Hashable then basically says that the domain > has a canonical representation. And Hashable would have to have > equality. So there would also be no need for modifying XHashTable. > As far as I can see this has nothing to do with representation. I agree that it makes sense to specify hashing only in the context of an appropriate equality. Maybe it is true that this is best handled by modifying the category structure rather than passing an additional parameter to XHashTable, but the way I saw it was that adding the additional parameter was not much worse than being able to pass a user specified hash function and stating in the documentation what conditions is should satisfy. >> However, weaker requirement on 'hash' would seriously limit >> its usefulness, basicaly to cases when one works with >> representaion. Since we want to hide representation, this >> is serious limitation. > > That goes into the same direction that I was proposing with > ExpressionRep (which was called LexicalExpression by Bill). > LexicalExpression could export Hashable while Expression would not. Expression already exports Comparable, although not OrderedSet. > Maybe LexicalExpression could be made useful for caching... I'm not sure > and actually not really interested in this code at the moment. > It sounds oddly inappropriate that you comment that you are "not really interested" :( >> Similarely, power series and streams are problematic (they are >> supposed to be lazy but hash function has to access elements). > > I don't think it makes sense to hash infinite structures. > >> The point is that I would like to eventiually remove >> unsoundness. If we allow new unsoundness to get in then >> there is almost no chance of removing unsoundness ... > > Good!!! I hope, some day Float no longer claims to be a Field. > Yes, I think this is a closely related problem involving different possible definitions of equality. Bill. -- 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.
