Load the Tetrads package, and choose Schwarzshild spacetime:

with(Physics):
with(Tetrads):
Setup(metric = schwarzschild,quiet):

Consider then the following code/output:

expr := D_[~mu](e_[mu,a]);
seq(simplify(SumOverRepeatedIndices(expr             )),a = 1..4);
seq(simplify(SumOverRepeatedIndices(D_[~mu](e_[mu,a]))),a = 1..4);

In my mind, the last two code lines are entirely identical, but their corresponding outputs are certainly not. I don't get it. The above can be compared with the following code/output in which the vierbein indices mu and a have been interchanged:

expr := D_[~mu](e_[a,mu]);
seq(simplify(SumOverRepeatedIndices(expr             )),a = 1..4);
seq(simplify(SumOverRepeatedIndices(D_[~mu](e_[a,mu]))),a = 1..4);

Here, the outputs are identical. The mystery becomes total when realizing that according to Maple, e_[a,mu] and e_[mu,a] are considered completely identical [a notational choice I do not find reassuring].

I have the following two questions/issues:

1.) It seems to me that in the Tetrads package, some tetrad is automatically calculated in terms of the metric. Is there any way to reverse the roles, i.e., to have the vierbein determine the metric?, as is anyway a more natural setup, I think. The point is that I would like to work with an arbitrary, non-fixed vierbein, and from it having the metric, Christoffel symbols, etc., calculated 'on the fly', and then ultimatively construct the socalled minimal spin connection from these quantities.

2.) Consider the following expressions:

Simplify(e_[a,mu ]*Christoffel[~mu,nu,rho]);
Simplify(e_[a,nu ]*Christoffel[mu,~nu,rho]);
Simplify(e_[a,rho]*Christoffel[mu,nu,~rho]);

As the Christoffel symbols do not transform as tensors, I find this notation unfortunate, as one cannot simply move the vierbein through a (partial) derivative. Conversion between world indices and Lorentz indices should, I think, only be performed for world indices of tensorial type.

Consider the following anticommutators:

with(Physics):
Simplify(AntiCommutator(Dgamma[1],Dgamma[1])),
Simplify(AntiCommutator(Dgamma[1],Dgamma[2]));

Being basic Clifford algebra, I wonder why Physics does not know that the second one should simplify to zero.

PS: Just to be sure, I have updated to Maple 2017.3 today.

I have some elliptic curve with some points on it:

I would like to give the points some names, P, etc., but cannot figure out how to do that probably simple task. The help pages ?plot,options and ?pointplot do not seem to cover it; I may be mistaken, of course. The above plot is the result of the following code:

curve := y^2 = x^3 - 43*x + 166;
display([
   plot(+sqrt(rhs(curve)),x = -10..12),
   plot(-sqrt(rhs(curve)),x = -10..12),
   pointplot([[3,8],[-5,16],[11,32],[3,-8]],symbol = solidbox)
]);

Update: Using, among other things, the textplot command as suggested below, here, just for the fun of it, a plot illustrating the group 'addition' of points on an elliptic curve, the three lines being tangents to the curve:

For sqrt(-1), Maple returns I. Why not -I? I understand why in general Maple does not, and should not, return both signs, because sqrt is defined with a branch cut - specifically out along the negative real axis:

FunctionAdvisor(branch_cuts,sqrt(s));

But as +I and -I lie symmetrically around the branch cut, I do not understand why +I should be chosen in favor of -I. Neither the square of +I or of -I crosses the branch cut, which is,  I guess, the standard way to select a unique value, although both squares end up on the branch cut itself - the latter fact leading to the following more general consideration:

I do not understand why the square root of any negative real number (the above being just a specific case) should at all be assigned any meaning when lying as they do on the branch cut itself. I think it would be more sensible if Maple raised an error, telling you that the branch cut needs to be changed/moved if any value is to be assigned. Which leads me to the following question:

Can the branch cut of the logarithm, and thus of sqrt as well, be changed/moved? I would like it to lie out along the negative imaginary axis.

Update I: Concerning -1 lying on the branch cut itself, there is no issue, see my 'ups' in the reply to the answer by John May. But redefining the branch cut is still relevant.

Update II: Perhaps the issue raised is not all that trivial, after all. At least, it is "a subject of papers and debate", as Alejandro Jakubi formulated it in an email to me, pointing me to the article 'Function evaluation on branch cuts', by Rich and Jeffrey.