On 6 April 2015 at 19:06, Waldek Hebisch <[email protected]> wrote: > Bill Page wrote: >> >> On 5 April 2015 at 11:50, Waldek Hebisch <[email protected]> wrote: >> > Bill Page wrote: >> >> >> >> Reading the definition: >> >> >> >> ++ An eltable over domains D and I is a structure which can be viewed >> >> ++ as a function from D to I. >> >> ++ Examples of eltable structures range from data structures, e.g. those >> >> ++ of type \spadtype{List}, to algebraic structures, e.g. >> >> \spadtype{Polynomial}. >> >> Eltable(S : SetCategory, Index : Type) : Category == with >> >> elt : (%, S) -> Index >> >> ++ elt(u, i) (also written: u . i) returns the element of u indexed by i. >> >> ++ Error: if i is not an index of u. >> > ... >> >> In any case, if a domain D does not have some concept of equality = >> >> (BasicType) does it make sense to talk about "a function from D to I"? >> >> >> >> Are there any domains in FriCAS that one might conceivably use as an >> >> index domain which does not export equality? >> > >> > Note that you wrote "a function". 'elt' is just a function, like >> > any other. So you ask if all domains should export equality? >> >> No. I think you misunderstood my point. Eltable is supposed to mean >> that any domain % that satisfies Eltable(D,I) has values "which can be >> viewed as a function from D to I". So it is not 'elt' itself but >> rather a value from % that needs to behave in this way. 'elt' is just >> the interface to this aspect of %. And as far as I can see having >> equality in D is an important part of this. > > Hmm. I do not get your point. If some domain or package exports > > foo : D -> Something > > then 'foo' can be viewed as a function from D to Something. So > I do not get why you think that 'elt' needs equality in D but > accept 'foo' for D with no equality. >
I am not concerned much about defining such a function, though maybe it would be a bit more clear if we had elt: % -> (S -> I) What bothers me more is the meaning of the category Eltable. In typical Axiom style we are not told very much about what it means. In some cases, e.g. Ring, not much more is needed than a reference to ring as a well-known mathematical object. But really we should probably expect a set of axioms to be associated with each category. What axioms should we associate with Eltable? We are only told that the members of % are "data structures" and "algebraic structures' that have some kind of "indexed elements". My point is that I suspect that we can not specify reasonable axioms for Eltable without requiring equality on S. Maybe I am wrong. >> > If equality in not computable, than having no equality is >> > natural. >> > >> >> Can you give an example? > > Canonical example are functions given by their code. Also > various lazy infinite structures like computable reals. > Ralf mentioned streams and series: currently we cheat and > provide fake equality but since real equality is not > computable it would be more natural to provide none. Then this should also apply to Expression, no? If not, then why can we not do for these other domains what we do for Expression? >> >> So how can the XHashTable domain tell TableAggregate whether or not to >> export 'table(hash,eq)' with two arguments but not to expect the same >> thing from a domain like AssiationList? Of course maybe it should >> also be available in AssociationList. Is that your point? > > 'table(hash,eq)' should be exported by XHashTable. We do not need > such export in TableAggregate. I we wished to create a more > general concept, allowing association lists with arbitrary > equality then we would introduce extra category. Alternatively, > if you think that all aggregates with search-like functionality > should allow 'eq', then you may go trough all domains and > adjust them. But association list should have no need of > 'hash', so this does not look like good generalization. > > AFAICS modification to XHashTable can be done without touching > any other domain, in particular other domains will not get any > extra exports. We need to adjust categories, but relaxed > parameters do not affect any existing domain. > So, with TableAggregate(Key: Type,Entry: Type), if we specify a Key that does not export =$key will TableAggregate still export 'table()' with no arguments? If so, what will XHashTable do to implement it? -- 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.
