In his e-mail message of 29-Sep-92 Ralf Dentzer wrote:
When I read the very good introductory chapter "About GAP" of the GAP
manual, some minor comments/questions came to my mind.
1) The contrary of "Intersection" is in many Categories not the "Union",
but the smallest object (domain), containing the given ones.
Such a function, maybe called "Compositum", would make more sense
We call it 'Closure'. Actually we only make it available for groups and
there subgroups. Is it really necessary to have this for the other
categories as well? If so I would suggest using 'Closure' instead of
'Compositum'. Opinions anyone?
2) Why are there no Iterators, generating all elements of a domain
exactly once, but without putting them all into a list.
This is easy to achieve for e.g. permutation groups,
and useful in various places. There could also be a
construct like "for a in D do" where D is a domain, and an
iterator is used to generate the a.
(Similar to "for i in [1..6] do")
We have plans to allow this. So that you can write
for <var> in <domain> do <statements> od;
This is a little bit difficult, because it should be possible to loop
over one domain several times in parallel. I.e., it should be possible
for g in D12 do for h in D12 do <do something with the pair g, h> od; od;
3) It seems to me that the definition of "<" in the ResidueClass
example in 1.28 leads to problems if you want to define two
new types of group elements independently and to compare
two of those. The problems arise if you want to put them
into a sorted list (a set).
Yes this is true. We simply don't know a good concept which would
guarantee a well ordering for all types of group elements, ring elements,
domains, etc. that one might want to define. So we (Frank Celler and I)
agreed that we simply would wait until somebody has a problem with it.
Our idea was that if nobody ever has a problem with it (because nobody
ever tries to make a set with group elements of different types), then
all the effort spent to come up with a concept would be wasted. And we
simply hate to waste effort.
I must admit that I could implement the proposals 1) and 2) (partially)
for myself, if I really needed them. Maybe the designers of GAP have
thought about these things and have their reasons for not doing them.
But if this is not case they are certainly better in doing a proper
implementation and defining a good standard for these things.
As I already remarked, we have no reasons for not doing proposals 1) and
2), but they are not very high on our priority list. If someone really
needs them, tell me, that will push them closer to the top.
Martin Sch"onert, Martin.Schoenert@Math.RWTH-Aachen.DE, +49 241 804551
Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany