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. > If equality in not computable, than having no equality is > natural. > Can you give an example? >> I guess I don't understand the desire to "generalize TableAggregate to >> require only Type on first parameter.". Is this just generalization >> for it's own sake or is there some conceivable use? Backing this up, I >> agree with Ralf that I also "would find it a little odd, if XHashTable >> cannot inherit from TableAggregate if Key is just of type Type". From >> my point of view this is a good reason to keep the requirement that >> Key has SetCategory even though I want to be able to pass my own >> custom equality when creating an XHashTable. Otherwise this would >> push the support for passing a custom equality all the way down to >> other domains which have TableAggregate. > > No. We are talking about _categories_ here. Any domain exporting > given category may impose stronger condition on parameters, and > all domains which need eqality in the parameter will still > require this. Modifying category means that domain like > XHashTable may have the same category like other domains, > without requiring any change in those domains. That is why > having weak conditions on parameters to categories make sense: > domain may always add extra restrictions to parameters, but > can not drop restricions introduced in the category. > 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? On 5 April 2015 at 11:50, Waldek Hebisch <[email protected]> wrote: > Bill Page wrote: >> >> On 4 April 2015 at 18:19, Waldek Hebisch <[email protected]> wrote: >> > ... >> >> On 04/04/2015 04:00 PM, Waldek Hebisch wrote: >> >> > I think that categories should make only minimal requirements on >> >> > parameters. So it is natural to generalize TableAggregate to >> >> > require only Type on first parameter. Some operations may be >> >> > conditional, for example 'removeDuplicates' assumes notion of >> >> > equality, so it make sense to require BasicType. >> >> >> >> It seems unclear to me what you might mean by "minimal requirements". >> When is the minimal requirement not just "none at all". If there are >> no requirements then we can always add them by making everything >> conditional. No? > > I think we normally want at least one unconditional signature. > The point is that we do not want to impose unnecessary conditions, > but also we do not want to play semantic games or go to > extraordinary effort to have weak (or no) conditions on parameter. > >> >> > Ralf Hemmecke wrote: >> >> So the first natural thing is to generalize >> >> >> >> Eltable(S : SetCategory, Index : Type) : Category == with >> >> >> >> to >> >> >> >> Eltable(S : BasicType, Index : Type) : Category == with >> >> >> > >> > Hmm, why not: >> > >> > Eltable(S : Type, Index : Type) : Category == with >> > >> >> 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. >> >> Do you notice anything strange about the documentation of this >> category? S is apparently the "domain" (D) and 'Index' is the >> "co-domain" (I) of the function represented by % referred to >> initially. So the name 'Index' seems like a very poor choice! >> Presumably a better name might have been 'Image' similar to 'Im' which >> is used elsewhere in reference to Eltable. It is actually the domain >> S that seems like an index to me and that is how it is treated in the >> definition of 'elt'. > > Yes, good catch. > >> 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? > If equality in not computable, than having no equality is > natural. > >> I guess I don't understand the desire to "generalize TableAggregate to >> require only Type on first parameter.". Is this just generalization >> for it's own sake or is there some conceivable use? Backing this up, I >> agree with Ralf that I also "would find it a little odd, if XHashTable >> cannot inherit from TableAggregate if Key is just of type Type". From >> my point of view this is a good reason to keep the requirement that >> Key has SetCategory even though I want to be able to pass my own >> custom equality when creating an XHashTable. Otherwise this would >> push the support for passing a custom equality all the way down to >> other domains which have TableAggregate. > > No. We are talking about _categories_ here. Any domain exporting > given category may impose stronger condition on parameters, and > all domains which need eqality in the parameter will still > require this. Modifying category means that domain like > XHashTable may have the same category like other domains, > without requiring any change in those domains. That is why > having weak conditions on parameters to categories make sense: > domain may always add extra restrictions to parameters, but > can not drop restricions introduced in the category. > > -- > Waldek Hebisch > [email protected] > > -- > 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. -- 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.
