Of course, it is quite correct that "christoffel" is a module (an object); that is the way it is constructed. Not having used "Gravitation" for a while this had slipped my mind. Just prior to your post I managed to insert ":-getComps()" which retrieves all components as an Array, and now it correctly gives the empty set

In connection with multi-dimensional Arrays, there seems to be a problem with the use of convert(...) in your expression. An example from gravitational calculus, using my package "Gravitation" [actually, my tip is taken from there; it is used in the procedure flattenNonZeroComps(...), see below]:

with(Gravitation):
metricComps := Array([
	[-(1-2*M/r),0,0,0],
	[0,1/(1-2*M/r),0,0],
	[0,0,r^2,0],
	[0,0,0,r^2*sin(theta)^2]
]):
metric := createMetric("LL",metricComps,[t,r,theta,phi]):
christoffel := deriveChristoffel(metric):
christoffel:-flattenNonZeroComps();

[[1, 1, 2] = M/(r*(r-2*M)), [1, 2, 1] = M/(r*(r-2*M)),
[2, 1, 1] = (r-2*M)*M/r^3, [2, 2, 2] = -M/(r*(r-2*M)),
[2, 3, 3] = -r+2*M, [2, 4, 4] = -(r-2*M)*sin(theta)^2,
[3, 2, 3] = 1/r, [3, 3, 2] = 1/r,
[3, 4, 4] = -sin(theta)*cos(theta), [4, 2, 4] = 1/r,
[4, 3, 4] = cos(theta)/sin(theta), [4, 4, 2] = 1/r,
[4, 4, 3] = cos(theta)/sin(theta)]

The quantity "christoffel" (the connection in Einstein gravity) is a three-dimensional Array. It does not seem to be convertible to an array [below, the components of christoffel, which is an object, is retrieved with the method getComps()]:

select(t -> type(christoffel:-getComps()[op(t)], posint),{indices(convert(christoffel:-getComps(),array))});

{}

Very nice; the shorter, the better! It automatically raises a question in my mind: Does there for Arrays exist a command analogous to indices(...)?

I'm not quite sure whether this answer of mine is what your are looking for, but generally when working with sequences, lists, sets, etc., an index is used to extract a particular item. An example (the quadratic equation) using solve:

sols := solve(a*x^2+b*x+c=0,x);
sols[1];
sols[2];

For nested sequences, lists, sets, etc., several indices are used. An example:

nested := [{1,2,3},{a,b,c}];
nested[1];
nested[2];
nested[1][2];
nested[2][3];

Yesterday evening it must have been too late for me doing maths, for the mistake is entirely mine: The sets themselves contained the names/variables a,b, and c, which are used as parameters in the seq(...)'s. Thanks for waking me up!

Yesterday evening it must have been too late for me doing maths, for the mistake is entirely mine: The sets themselves contained the names/variables a,b, and c, which are used as parameters in the seq(...)'s. Thanks for waking me up!

No doubt, your idea is good. I just wish I had the discipline for doing that. Instead I just press on, naively hoping that the ever more frequent glitches in my memory, compared to when I was twenty, will some day be gone (of course the truth is quite the opposite).

No doubt, your idea is good. I just wish I had the discipline for doing that. Instead I just press on, naively hoping that the ever more frequent glitches in my memory, compared to when I was twenty, will some day be gone (of course the truth is quite the opposite).

This does not seem to work in Maple 9.5, which I'm using; it seems to mix the sets/lists in some mysterious way, for instance taking two times the same item from some set/list.

This does not seem to work in Maple 9.5, which I'm using; it seems to mix the sets/lists in some mysterious way, for instance taking two times the same item from some set/list.

Maybe I should have a go; I have just spend a little time reading about Maple 11, and it seems (of course, when it comes to marketing, one should be a little careful not to be naive) to be a real improvement on Maple 9.5.

Maybe I should seriously consider upgrading. But before doing so I would appreciate hearing anybodys experience concerning backwards compatibility of Maple 11; does it run Maple 9.5 worksheets without incidents?