@ecterrab: Super, it works.

@Axel Vogt: It suddenly dawned upon me that perhaps the problem is present only when the Physics package is loaded. And that is actually the case. Accordingly, I have added a note to my original posting. It would seem that this is a question for Edgardo Cheb-Terrab, and thus I have changed the tags list to include 'physics-package'.

@ecterrab: I have now installed the new version, and it does indeed seem to work fine. Thanks.

@Alejandro Jakubi: Thanks for that information.

@Axel Vogt: The result of using simplify,

is indeed far more reasonably looking. But it would surely have been even nicer if the result would have been something like

As I dare not contemplate how this will play out in higher dimensions, I think I will abandon the strategy of using complex-valued matrix entries, and instead try out the following: As a matrix constructor for a hermitian matrix use something like

Matrix(3,(i,j) ->
   if   i < j then a||i||j + I*b||i||j
   elif i = j then a||i||j
   else            a||j||i - I*b||j||i
   end if
);

i.e., drop completely the shape = hermitian option; and then use map(evalc,...) throughout to force Maple to evaluate any expressions as if the a's and b's are real-valued.

@Axel Vogt: I had a hunch that the problem might be related to my choice of indets (I had noticed that it consisted of six elements). Therefore I tried to use instead the explicit

{m11,m22,m12,conjugate(m12)}

but it made no difference. I did not know that indets may be used with a type as argument. Thanks for that tip. I think, though, that the resulting matrix M:

although now being properly hermitian, is less than optimal: I suppose that the 22-entry of the matrix equals just Re(m11), for among all hermitian 2-dimensional matrices it is only the (real) span of the identity matrix and P itself that commutes with P.

Trying now to work exclusively with complex-valued matrix entries leads to a new problem for me: The code

M := Matrix(2,(i,j) -> if i = j then Re(m||i||j) else m||i||j end if,shape = hermitian):
M,type(M,'Matrix'(hermitian));

produces the following perfectly sensible output:

But if I want, say, to consider only those M's that commute with the first Pauli matrix (denoted P below):

P := Matrix([[0,1],[1,0]]):
M_SOL := eval(M,solve(convert(P . M - M . P,set),indets(M))):
M_SOL,type(M_SOL,'Matrix'(hermitian));

then hermiticity is lost:

What is going on? How can the evaluation of a hermitian matrix (with respect to some solution) produce a non-hermitian one? Am I just being daft (again)?

@Preben Alsholm: It is beginning to dawn on me that for years I have been sloppily and illegitimately assuming that the quantities I used in the matrix constructors (i.e., the a's and b's above) were considered real by Maple. I clearly have to be more careful.

Thanks to you all in this thread for getting my head around this, hopefully.

@Axel Vogt: Thanks for that variation. Following it, consider the code below:

M := map(evalc,
   +Matrix(3,(i,j) -> a||i||j + I*b||i||j,shape = hermitian)
   +Matrix(3,(i,j) -> a||i||j + 0        ,shape = diagonal )
);
type(M,'Matrix'(hermitian)),map(evalc,HermitianTranspose(M) - M);

It produces the following output:

M being constructed as a sum of two matrices with different shapes, the false may make sense in a strictly speaking manner, but intuitively it makes no sense to me when at the same time the expression map(evalc,HermitianTranspose(M) - M) returns the zero matrix, indicating that M is indeed a fully legal hermitian matrix.

@Carl Love: Now I understand what you mean; thanks for elaborating.

But I cannot help wondering why Maple does not raise a warning (when non-consistent indicator functions are used, see the post of Axel Vogt above), rather than reverting to zero for the diagonal elements? Some months ago, while still working with Maple 9.5, this threw me off track for some hours, before I tracked down the 'error' of mine.

PS: Thanks for adding a tag to the main post of mine.

@Carl Love: Please forgive me, but I do not understand your point. Please elaborate, if possible.

@Alex Smith: Yes, for the version of M given in my first post of this thread, it should indeed return Re(a||i||j + I*b||i||j), I completely agree. But for the post of mine titled 'Ad hoc behaviour' it should, of course, only return Re(a||i||j).

@Carl Love: In the first code, if Maple does not know/assume that a||i||j is real, then why could it not just, quite consistent with the property shape = hermitian, return Re(a||i||j) as the diagonal elements, in which case it would actually become completely equivalent to the second code?

@Adri van der Meer: Thanks for your suggestion. Naively, I would expect your code to be equivalent to the following [where I have included also map(evalc,...), along the lines of Preben Alsholm's comment]:

M := map(evalc,Matrix(3,(i,j) ->
   if i = j then a||i||j
   else a||i||j + I*b||i||j
   end if,
shape = hermitian));

But it is not, this alternative code giving zero diagonal elements, too. Your code is equivalent to the following, though:

M := map(evalc,Matrix(3,(i,j) ->
   if i = j then Re(a||i||j)
   else a||i||j + I*b||i||j
   end if,
shape = hermitian));

This behaviour of Maple seems to me worryingly ad hoc. If Maple thinks that evalc(Re(a||i||j)) equals a||i||j in the second code, i.e., that a||i||j is indeed real-valued, as one would here expect, why then does it have no effect in the first code?, I ask myself.

@ecterrab: I had not expected a reply from a MapleSoft employee, and I do not mean that reproachfully, of course. I have installed the update according to Option 1 of 'Install guide for the updated Physics Library for Maple', and it runs correctly. Thanks for your help.

I do wonder, though, why a commutator and anticommutator are not, and have never been, implemented as exports of the LinearAlgebra package to where I think they would naturally belong, as least for matrix-valued arguments. Of course, the commutator and anticommutator of the Physics package is more general as they accept also algebraic arguments (both commuting and anticommuting ones).