In his e-mail of 1993/02/12 (actually it arrived here a little bit
earlier, but not from his subscription address, so I had to stuff it into
'listserv' by hand) Jean Michel asks why GAP doesn't allow vectors of
length zero.

He writes:

Given a list l1,..lr of integers (with no holes -- recognized as a
vector by Gap). I want to construct the list (1,..,d,l1+d,...,lr+d).
So I wrote:

gap>shift:=function(l,d)return Concatenation([1..d],l+d);end;

What is the problem? This does not work when l is empty: I get

"Error, Vectors: '+' incompatible types"

Actually this will work in GAP 3.2, but it probably should not be relied
upon to work in later releases.

He continues

Indeed, when asked:

gap>IsVector([]);
false

Is not this wrong? The vector space of dimension 0 is a perfectly valid
mathematical object -- How to represent its elements?

I beg to differ. The vector space of dimension 0 *over a given field* is
a perfectly valid object. But if we represent vectors in such a vector
space by lists of length zero we have way to find the field this vector
lies in.

Why is this a problem? Well, what is the scalar product of two empty
vectors? Zero, of course. But which zero? The integer zero, or the
zero from a finite field (but of which characteristic), or the zero
polynomial over some ring? This is basically the problem. We have no
way to find a field for such an empty vector (and thus the zero).

He contiunes:

Example 2:

I need to compute an echelonized basis of the space generated by a set of
vectors. If s is this set (represented as a list of vectors),
TriangulizeMat(s) works well excepted when the set is empty:

gap>TriangulizeMat([]);
Error, ... because in the code of the function Length(mat[1]) is taken.

Would not it be easy to fix it so that TriangulizeMat([])=[] ?

Yes, it would be easy to fix 'TriangulizeMat', and I see no problem with
this. Expect this to happen in the near future.

He continues:

these 2 examples seem to me a symptom of a wrong treatment of empties in
GAP, which forces to add ugly and unnecessary code to handle special
cases. GAP has only one kind of empty, the list [] (in contrast to
languages like APL where an empty matrix still may have a shape like
[0,5]). This is fine with me, but then all operations which logically
should accept empty vectors(or matrices, or whatever...) should also
accept [].

I would formulate this slightly different (though I agree that there is
a problem). In GAP certain information about a vector or a matrix
is simply implicit. For example with vectors the field over which this
vector lies is derived from the entries of this vector. This is why a
vector must have at least one entry. Another example are matrices.
The shape of a matrix is derived from its length and the length of its
rows. Lets for the moment assume that vectors of length zero were legal.
Then we could create a matrix of shape [5,0], namely [[],[],[],[],[]].
But we could not create a matrix of shape [0,5], because how could GAP
guess that each row has length 5, if the matrix has no rows.

Because GAP tries to read of information (the field and the dimension)
about a vector or a matrix from the entries (the elements or the rows)
such a field or matrix may not have zero length.

In spite of this problem I still think that GAP's approach is a good one.
In GAP 2.4 vectors and matrices were different datatypes, and the
neccessary conversions between lists (of lists) and vectors or matrices
were quite a pain. In GAP 3, where everything is just a list, you have
all the powerfull list operations and functions available to apply to
vectors, matrices (and sets too). You can simple extract elements from a
matrix with m[i][j] or change them with an assignment (which you could
not in GAP 2.4).

He continues:

I cannot see any big problem with IsVector([]) being true,
but it being false certainly gives me problems.

I hope I could convince that there are problems.

Martin.

-- .- .-. - .. -.  .-.. --- ...- . ...  .- -. -. .. -.- .-
Martin Sch"onert,   Martin.Schoenert@Math.RWTH-Aachen.DE,  +49 241 804551
Lehrstuhl D f"ur Mathematik, Templergraben 64, RWTH, D 51 Aachen, Germany