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?
> 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'.
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?
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. Do we really want to do that?
--
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.
