I do know what "a kitchen sink" is. Here in Denmark it is called "en køkkenvask". Thanks for your thoughtfulness.

You natively english speaking guys do have an advantage over a foreigner like me: quite often I have to consult my danish-english and english-danish dictionaries to be sure that I am not abusing a word - but it is very educative.

Of course, you are right that any high ranked tensor would be problematic with respect to storage.

It may come as a complete surprise to you, but I have actually never used the sparse option of an Array. Quite obviously that is something I will have to remedy.

I begin to see the advantage of your approach, having only one indexing function (which may take up quite some memory, depending on rank and dimensionality) for each class of tensor (anti)symmetries, and sparse Arrays for the tensors (each taking up only little memory).

You have some very important points there. I am afraid that I will have to rethink what I want to achieve.

Thanks for this very explicit post of yours.

What makes me feel a bit uncomfortable about your approach, though, is that I am trying to create a framework that works, in principle, for any rank of the tensor. Imagine, for instance, what happens for a rank 10 tensor: in four dimensions it would yield 4^10 = 1048576 table entries.

Thanks for that significant observation. I had not thought about that, sadly. So, as you write in your other post I should rather generate only once an indexing function for each class of tensor (anti)symmetries. Back to the drawing board for me.

That sounds interesting. I am curious: what is a "kitchen sink" in Maple?

That sounds interesting. I am curious: what is a "kitchen sink" in Maple?

I also think that this version with two map's is very clean. I am happy to find out that my aesthetical feeling here agrees with the one of a master like you.

Thanks, Jacques and Joe, for your sharp observations. I prefer the double map version, so that my code lines would look like:

posMaps,negMaps := seq(
	map(perm -> unapply(map(i -> x[i],perm),x),perms)
,perms in [posPerms,negPerms]);

The blog entry Refactoring Maple code has yielded some very nice improvement of the first part of permsPosNeg.

However, what really worried me the most was the use of the while loop which by iteration builds the positive and negative permutations of the entry ind. Is there any noniterative way of doing the same thing?

Thanks, Jacques. Not only does it make things faster for larger permutations (something I take your word for), but it also makes posMaps and negMaps look nicely simple (as seen using printlevel := 10).

I completely agree with you that something like t_particle, t_photon, and t_asymptote is the correct notation. I guess my choice boils down to sloppyness on my behalf.

The main difference between our approaches seems to be that we have switched around the abscissa and the ordinate.

I completely agree with you that something like t_particle, t_photon, and t_asymptote is the correct notation. I guess my choice boils down to sloppyness on my behalf.

The main difference between our approaches seems to be that we have switched around the abscissa and the ordinate.

With regard to the separate call to seq, you assumed correctly. I was not overly concerned with making the code as short as possible, more with making it transparent.

With regard to the separate call to seq, you assumed correctly. I was not overly concerned with making the code as short as possible, more with making it transparent.