> < ^ From:

> < ^ Subject:

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([]);

falseIs 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

> < [top]