# UnitaryMatrixQ function not returning true for a unitary matrix

So I know this matrix is unitary. It's a well proven fact in quantum mechanics and you can even check for yourself on pen and paper, Heres a quick proof:

Assume $H$ is hermitian (i.e. $H^\dagger=H$) Then Define $U=\exp(-iH)$.

We can see that $U^\dagger=\exp(iH^\dagger)=\exp(iH)$

And that $U^\dagger U=UU^\dagger=\exp(iH-iH)=\exp(0)=I$

Belive me? Okay, So here's my mathematica code:

H = {{Re[a], b},{Conjugate[b], Re[c]}};
HermitianMatrixQ[H]
U = MatrixExp[-I H];
UnitaryMatrixQ[U]


And the output is True for the first query and False for the second. What gives?

Looking further into this, I think there are some expressions mathematica is getting confused about. If I express the hermitian matrix slightly differently, then do the same thing, I get this very strange result:

H = {{Re[a], Re[b] + I Re[c]},{Re[b] - I Re[c], Re[d]}};
U = MatrixExp[-I H];
FullSimplify[U\[ConjugateTranspose].U]
UnitaryMatrixQ[U]


which has the output:

{{1,0},{0,1}}

False


Which is just a straight up contradiction!

--- follow up ---

If I try the second codeblock, with the representation of the hermitian matrix as it is in the first, then mathematica runs for a very long time (too long for my computer at least)

• Interesting observations. I never used these functions. There's this (as far as I know unwritten) rule that ...Q functions will always return either True or False but nothing else. Think Equal vs SameQ. a==1 stays unevaluated but SameQ always evaluates. It's also a reason why Positive is not PositiveQ: Positive[x] does evaluate until x gets a value. In light of this I find it a little strange that UnitaryMatrixQ and HermitianMatrixQ have the ...Q naming and behaviour. Is {{a,b},{c,d}} Hermitian? Well, it depends on the value of b and c! Commented Feb 10, 2016 at 22:21
• But the function just says False. So maybe this should be interpreted as "Hermitian for any value of a,b,c,d"? But that interpretation brings its own problems too: sometimes the system just won't be able to check and come to a certain conclusion, yet the function will always return either True or False. So what is going on? I think that what is really happening is that the function computes the required criterion (i.e. $U\dagger U=I$), but then leaves it to the SameTest setting to test that condition. You can set this manually and the documentation gives an example where Commented Feb 10, 2016 at 22:25
• it is SameTest -> (FullSimplify[#1 - #2] == 0 &). If the SameTest doesn't return an explicit True, it is automatically assumed to be False (as if TrueQ were applied to it, think TrueQ[a==1]). At least that's my idea about what is happening. Thinking about it like this explains the behaviour and makes some sense. I'm not sure if these comments constitute an answer ... I'll leave them as comments for now. Commented Feb 10, 2016 at 22:28
• Yeah sure, I could get that if It can't work it out, then it would just return false. But If it can work out that FullSimplify[U\[ConjugateTranspose].U]=={{1,0},{0,1}} Then you'd think it could work it out with the Query. Perhaps those bits of code need a little tlc... Commented Feb 10, 2016 at 22:46

## 1 Answer

tl;dr If these functions cannot decide, they will simply return False. A False result means that the selected equality testing method wasn't able to prove equality, but it does not mean that it was able to prove inequality. Interpret the result relative to the used SameTest option value.

I will try to explain what I think is happening, though some of these are guesses.

First some background

...Q functions always return either True or False in Mathematica. I have not seen this explicitly documented, but it seems to be true. Examples:

Equal[a,b] does not evaluate for undefined a and b. SameQ[a,b] will always give True or False.

Positive[a] does not evaluate until a gets a numerical value. It does not evaluate if the system cannot prove that the value is truly positive. It won't give False in these cases. It is not a ...Q function.

PossibleZeroQ is a ...Q function and will always give a definitive yes or no answer. But the naming does reflect that this answer may not be correct.

TrueQ is often used to force a definitive True or False answer when this is needed. E.g. TrueQ[a==b] will return False when a and b have no values.

HermitianMatrixQ and UnitaryMatrixQ

Symbolic calculations can not always be done. In fact deciding whether an arbitrary expression is identically zero is an undecidable problem. Thus I was surprised to see that these two functions are of the ...Q variety and always return a definitive yes/no answer.

The only way I can make sense of this is if I think about these functions in a different way. They do not actually check if a matrix A is Hermitian. That check might not be possible at all, and oftentimes the answer would have to be "I don't know". Instead HermitianMatrixQ does this:

• Compute A == ConjugateTranspose[A].
• Use the SameTest setting to test for the equality.
• If the test gives True, return that. Otherwise return False, even if the test fails to give a definitive answer (like TrueQ).

The documentation does not make it clear that this is what these functions do, but it appears to me that this is what is happening in reality.

The documentation however does give examples of special SameTest settings, e.g. here:

 SameTest -> (FullSimplify[#1 - #2] == 0 &)


This setting will make your second example return True

H = {{Re[a], Re[b] + I Re[c]}, {Re[b] - I Re[c], Re[d]}};
U = MatrixExp[-I H];

UnitaryMatrixQ[U, SameTest -> (FullSimplify[#1 - #2] == 0 &)]
(* True *)


Without this explicit SameTest setting we get False because the default SameTest is just not smart enough to prove this equality (but at least it is much faster than FullSimplify!)

What is a bit frustrating about this is that the default SameTest is unknown (hidden behind Automatic). My guess is that it depends on whether the matrices are symbolic/exact or inexact numerical.

While this answer may not be what you were hoping for, I think that this way of looking at these functions will clarify what is happening.

• @Xavier Thank you for the comments, I did not know that. Is it otherwise generally true what I said about Q functions? Are you aware of other exceptions (which are not as trivial as IsomorphicGraphQ saying that multigraph isomorphisms is not yet implemented)? Commented Feb 11, 2016 at 8:07
• Ah, you are right, I assumed that the default value of SameTest was SameQ, but this not the case for HermitianMatrixQ. It is written that the default value is Automatic as you said. I may have seen this default value for another function using SameTest. I will try to find again which one it was.
– user31159
Commented Feb 11, 2016 at 16:22
• @Xavier In practice Automatic means that it could be anything. It could be as simple as SameQ or Equal or it could be a custom function not available to us users. This is pretty common (and pretty annoying) with Mathematica. One example is the ComplexityFunction option of Simplify. People have been asking about this so much that they finally included it in the documentation. But Automatic generally means: unknown unless explicitly documented. My guess is that it's not a single function but selected based on the type of matrices. It is likely different for numeric and symbolic. Commented Feb 11, 2016 at 17:10
• @Xavier While sometimes annoying, these Automatic settings are understandable. They want to provide a reasonable default for users, depending on the input. I just implemented a Method option for a shortest path function in IGraph/M today. The default is Automatic and the method it chooses depends on whether the graph is weighted or not, whether there are any negative weights, and the size of the graph. Overall it tries to choose the fastest way that is likely to work well. Commented Feb 11, 2016 at 17:15
• Yes, I agree about Automatic. I assumed that all SameTest were set by default to SameQ (rather than Automatic was always SameQ for SameTest), I guess I never paid close attention to the "Details and Options" section of the respective Qfunctions reference pages. Anyhow, this confusion is removed now, which is good. Also, thanks for the link to your package, I just downloaded it, I'll have a look at it.
– user31159
Commented Feb 12, 2016 at 0:15