On 23 March 2015 at 18:27, Ralf Hemmecke <[email protected]> wrote: > On 03/23/2015 03:41 PM, Bill Page wrote: >> The following patches provide hashUpdate! and as a result hash >> functions to the Expression, Kernel, Float and Complex domains. > > Looks OK to me. And if these domains export SetCategory (which is true) > there should be an implementation of hashUpdate!. >
Yes, these functions were expected but the implementation was missing. >> Also included is a patch to XHashTable to optionally pass a user >> specified function representing equality in the key domain. This is >> important for the use of XHashTable in domains like Expression where >> equality is not canonical. > > I see what you are aiming at, but I'm not sure whether I should support > your particular patch. Anyway, hashUpdate! has nothing to do with > XHashTable. So if your stuff is accepted, it should be two separate commits. > Well, I didn't see any immediate point of implementing these missing functions until I wanted to use them with XHashTable and I did not want to use the equality provided by these domains. > However, if you modify the code to allow an eqFunction in a table > construction, then I see no reason to require the Key parameter > http://fricas.github.io/api/XHashTable > to be of type SetCategory. I suppose so. > The export of > > table: (Key -> I) -> % > > could be made conditional "if Key has SetCategory then ...". > OK. > In fact, it seems you would like to construct > > E ==> Expression Integer > T ==> XHashTable(E, ENTRY) > > and then create the table with > > t: T := table(hash$E, eq) > > but which function eq (other than =$E) would make sense in that place? > Yes. Typically I would want to use "lexical" equality in Expression, i.e. (x,y) +-> not (smaller?(x,y) or smaller?(y,x)) > If you use =$E and have two expressions e1 and e2 (with e1=e2) that have > different representation, then storing some entries with keys e1 and e2 > will (most probably) give 2 table entries since hash(e1) will be > different from hash(e2). Your specification says that for that case you > would simply consider e1 and e2 not equal with respect to the given eq > function. So that would also give two table entries. > I want to be able to provide one value of ENTRY for a given E and another value of ENTRY for another lexically/syntactically different E even if these two expressions are equal in the sense of =$E. It seems to me that if I do not provide a compatible equality then this can not be guaranteed. Am I wrong? > This sounds like it would make more sense creating a domain > ExpressionRep(X: ...) that exports the equality from the underlying > representation and then define > > Expression(X: ...): ... == ExpressionRep(X) add > Rep := ExpressionRep(X) > ((x: %) = (y: %)): Boolean == (x - y) =$Rep 0 > > Then you are able to use > > XHashTable(ExpressionRep(X), ENTRY) > > and use =$ExpressionRep(X). > ??? I do not want to change the definition of the existing domain Expression. Maybe you meant I could use a domain such as LexicalExpression(R:Comparable): FunctionSpace(R) join ... == Expression(R) add ((x: %) = (y: %)):Boolean == not (smaller?(x,y) or smaller?(y,x)) Yes, perhaps that could be done but seemed less sensible to me. > I'm somehow missing some concrete use case to find you patch to > XHashTable useful. > E.g. Caching in the Kernel domain. Regards, Bill Page. -- 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.
