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.
