Oh boy, all those plot options :-).

I guess that it boils down to too little plot experience on my behalf.

You can use export, see the help page ?module,export, as in the following example:

m := module()
	export a,b,c;
	a := 10;
end module:
m:-a;
                               10

Note that variables declared as exports cannot also be declared as locals. You can retrieve the exports of a module as follows, see the help page ?exports:

exports(m);
                            a, b, c

You guessed correctly: I want to use the attributes for controlling the sign of the permutations of the indices. After many different approaches I am now narrowing in on what I think is the best approach - however, I might be proved wrong, once again.

Shortly after posting I realized that there was no need to use an equation as an attribute, just as you now suggest. I can just use the values +1, -1, and 0 themselves. Anyway, thanks for your suggestion.

I think you are right because if I dismantle, for instance, the expression it looks correct. But that, of course, does not make the gui bug less annoying: it sort of makes me loose confidence in the use of attributes.

Quite well-deserved.

For instance, I have recently benefited greatly from his suggestion concerning the implementation (still working on it) of (anti)symmetries of tensors.

Thanks for reminding me, I usually seem to forget about performance issues.

I would have no objection to something like numbops as numbops(3), say, is clearly simpler than satisfies(s -> evalb(nops(s) = 3)).

I did not know about satisfies, which is indeed very handy. In Maple 9.5, an explicit evalb is needed, though, yielding

type({1,2,3}, And(set,satisfies(s -> evalb(nops(s) = 3))));
type([1,2,3], And(list,satisfies(s -> evalb(nops(s) = 3))));

where I have used the same construction (I do like symmetry) for sets. However, I do wonder why something like

type({1,2,3},'set'(3,posint));
type([1,2,3],'list'(3,posint));

has not been implemented. Anyone on that issue?

Almost by accident, today I stumbled upon the following help page which is relevant for this thread:

?type,surface

Just for the record.

Almost by accident, today I stumbled upon the following help page which is relevant for this thread:

?type,surface

Just for the record.

I have reached the very same conclusion: there cannot be any overlap between various (anti)symmetries. Using your idea of using (symmetric and antisymmetric) tables, I am now working along the following lines:

The (anti)symmetries come in different levels, from level one and upwards, the higher levels building upon the lower ones. I am considering using a notation in which, for instance, the indexing function of the Riemannian curvature tensor may be created as

addPermIndex("riemann",
	a1 = [1,2],a2 = [3,4],	# Level one
	{a1,a2}			# Level two
);

where addPermIndex is, of course, not the one previously defined. Here, a1 and a2 are antisymmetries, as given by lists, and {a1,a2} is a symmetry, as given by a set. a1 and a2 are level one, and {a1,a2} is level two. With this notation, as compared with my original notation, it should be much easier to implement in general your approach using tables. Of course, there are things that must be checked, for instance:

• As already agreed upon, there cannot be any overlap at level one. This generalizes to any level: for instance, the following rank six indexing function should not be allowed because {a1,a2} and {a2,a3} overlap:

  addPermIndex("rankSix",
  	a1 = [1,2],a2 = [3,4],a3 = [5,6],	# Level one
  	{a1,a2},{a2,a3}				# Level two
  );
  

  Actually, this particular indexing function is, I believe, equivalent to the following one with no overlaps:

  addPermIndex("rankSix",
  	a1 = [1,2],a2 = [3,4],a3 = [5,6],	# Level one
  	{a1,a2,a3}				# Level two
  );
  

• At each level the number of indices must match: for instance, in the symmetry {a1,a2}, the antisymmetries a1 and a2 must each have the same number of indices (as they here do).
• At each level the "types" must match: for instance, it would make no sense to have something like {s,a}, with s being a level one symmetry, and a being a level one antisymmetry.

Thanks, Joe, for your very interesting approach which I will scrutinize. There are two immediate issues to contemplate:

• Of particular importance is the question whether or not any nontrivial (see below) set of (anti)symmetries is always a group-wise one. If that is the case, then most probably your approach is the way to go because it resolves the performance and storage issues.
• The user, though, should not have to think about how to implement the (anti)symmetries of some indexing function. The user should only be concerned with entering, as given in my original code, the positive and negative permutations. Then some code should, if possible, transform that into group-wise (anti)symmetries, in analogy with your procedure Riemannian.

The second issue is nicely connected with the first one: if some code exists that transforms any nontrivial (anti)symmetries into group-wise ones, then the answer to the former is affirmative. By nontrivial I mean an indexing function which allows nonzero entries somewhere. For instance, the following rank two example is clearly trivial:

addPermIndex("rankTwo",{[2,1]},{[2,1]}):

But what about the following rank three example, which is symmetric in the first two indices, and antisymmetric in the last two?

addPermIndex("rankThree",{[2,1,3]},{[1,3,2]}):

It is in fact trivial too (most fortunate because it is not group-wise, unless I have misunderstood your use of that term), but it is not obvious to me. Because higher rank examples will only make worse this ignorance of mine, some general method for settling this issue has to be established.

You are correct that the indexing tables themselves can profit from the sparse indexing option, but only for antisymmetries of the tensor, because only antisymmetries imply only-zero-assignable entries.

PS: I am happy to be able to say, that I have quite often used the antisymmetric indexing function for both matrices, arrays, and tables. So, luckily, I am not completely lost in "indexing space", only partially.

I actually suspected that, because I have seen you writing in French at this forum, and I know that Canada does have both English and French as main languages.

PS: Even though I am trying to show-off a bit in the title, please do not think that I am anywhere near fluent in french (actually, I had to look up évier, hope it is correct) - so english for me, please :-).

I actually suspected that, because I have seen you writing in French at this forum, and I know that Canada does have both English and French as main languages.

PS: Even though I am trying to show-off a bit in the title, please do not think that I am anywhere near fluent in french (actually, I had to look up évier, hope it is correct) - so english for me, please :-).

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.