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 form 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.
> > 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 infinte 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.
> >> 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?
'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.
--
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.
