> < ^ Date: Mon, 15 Feb 1993 17:31:02 +0100
> < ^ From: Joachim Neubueser <joachim.neubueser@math.rwth-aachen.de >
< ^ Subject: Re: problem with empties in GAP

Dear Professor Michel,
I am answering your letter of February the 15.th to the GAP forum
since Martin Schoenert is absent from Aachen for the next two weeks.
Let me first summarize the point of the discussion as I see it, namely
the question in how far GAP supports the interpretation of empty lists
as vectors and allows typical vector operations with them. At the end
of today's letter you offer two different viewpoints of the situation:

First the "pure object-oriented: everything has a type ...". This is
clearly not the viewpoint adopted in GAP 3.1 for the interpretation of
lists as vectors, as Martin Schoenert explained to you in his letter.
Such a puristic viewpoint had been tried in GAP 2.4 and has been
discarded and removed in the transition from 2.4 to 3.0 since we
learned by experience that it created a lot of practical problems. In
so far it is unnecessery to state that if this was the viewpoint taken
then the design of GAP would be terrible flawed. This viewpoint is not
taken, you know it and Martin said it.

Second the "functional: a unique data model (list) serves a varity of
purposes...". This is indeed the viewpoint presently taken in GAP, and
again Martin has explained this. Also indeed in a number of cases, GAP
does try to use the context in order to interpret what an operation
should mean in situations where, from a strict mathematical point of
view, the operation is not defined. For instance, if you want to
multiply an integer by a finite field element, GAP does return a
finite field element although, strictly speaking, the two factors are
from different domains. All you seem to ask for is an extension of
the ability of GAP to "guess" from the context what is meant. That
this is indeed all you ask for is demonstrated by the fact that you
are willing to allow an error message in case of a scalar product of
two "empty vectors". GAP did return an error message in a place where
it disturbed you, but in principle the two places aren't all that

Such request as shown by the problems that you mention in your first
letter is certainly reasonable and ought to be discussed if problems
of the commodity of using GAP have arisen as it has been the case with
you. I do not think, however, that such a request is a reason to use
in a public worldwide discussion terms like you have chosen in your
letters, like talking of "a wrong treatment of empties" or "an
unnecessary confused answer" and the like. While we are grateful for
each notification of a real bug, and while we appreciate every
suggestion for the improvement of GAP, I am not willing to accept that
users of GAP use a tone in the discussion with us like an impatient
teacher may (but should not) use with a dumb student.

In detail: Martin's answer that adding an integer to an empty list
will work in GAP 3.2 but one should not rely upon this to work in
later releases means: This possibility --which will not be mentioned
in the manual of GAP 3.2-- exists in GAP 3.2 but the rather difficult
question how to treat such border cases as addressed by you under the
present viewpoint of GAP in more generality may find another answer
later, forced upon by further experience.

As to the possibility of doing the kind of operations you would like
to have with empty vectors: GAP offers you to define a new data type
"vector over a fixed field and of fixed dimension" using records in a
similar way to the one explained in the section "About Defining new
Group Elements". Of course some functions have to be written for
that, and also it has to be expected that operations for this new type
will be less efficient. A student of Professor Schoenwaelder here has
indeed experimented with this in a similar case in order to avoid
difficulties with the start of a recursion.

Sincerely yours
Joachim Neubueser.

> < [top]