Bug introduced in 10.0 and fixed in 10.2.0

I found a case where calling one built-in function (HermitianMatrixQ) for a given matrix changes the behavior of another built-in function (AntihermitianMatrixQ) for the same matrix object. Here is the code:

M = {{0, 1}, {-1, 0}}

AntihermitianMatrixQ[M]    (* output: True *)
HermitianMatrixQ[M]        (* output: False *)
AntihermitianMatrixQ[M]    (* output: False -- WRONG! *)

I observed this in Mathematica on Microsoft Windows (64-bit).

The behavior is "stateful" in the sense that re-evaluating the assignment to M restores the correct behavior of AntihermitianMatrixQ until the next time the function HermitianMatrixQ is called for the same object, from which point on AntihermitianMatrixQ gives the incorrect result again.

I did some experimentation and found the following:

  • The "state" is per object: When you define several array variables, the functions behave independently for each of the array objects, in the way described above.
  • The problem does not occur for all matrices, but it is not limited to the given 2x2 case, either. (In fact I found it when debugging a calculation with 4x4 Dirac gamma matrices.)
  • The function SymmetricMatrixQ intereferes with the behavior of AntihermitianMatrixQ in the same way.
  • The result of AntisymmetricMatrixQ is affected in the same way.
  • Printing the FullForm of the object does not give any indication of a change to the object itself.

My question is therefore:

  • Does Mathematica store any per-object data for matrices that is not displayed in FullForm but that can affect the behavior of functions as described above?
  • If so, is there any way to display or to clear this kind of additional data?

Note: I created a support request with Wolfram Research regarding this strange behavior. So far I got no response, however. I would also appreciate independent confirmation of this behavior, to exclude the possibility that something is wrong with my particular installation of Mathematica.

UPDATE: I got a response to my support request (CASE:3202743) from WRI. They confirm that AntisymmetricMatrixQ is not behaving properly and that an incident report has been created. Many thanks also to @ilian for pursuing this matter. I would still be interested in answers to my questions as formulated -- both out of curiosity and in order to improve debugging options.

  • 1
    $\begingroup$ I see the same behavior on OS X MMA ver. $\endgroup$
    – N.J.Evans
    May 7, 2015 at 21:29
  • 5
    $\begingroup$ Thank you, I've submitted a bug report to the appropriate developers. $\endgroup$
    – ilian
    May 7, 2015 at 21:45
  • 2
    $\begingroup$ I see the same behavior in MMA ver. 10.1.0 on Win7-64bit. This is weird! $\endgroup$
    – MarcoB
    May 7, 2015 at 21:45
  • 2
    $\begingroup$ I think a workaround might be to use an explicit SameTest. {AntihermitianMatrixQ[m, SameTest -> (Simplify[#1 - #2] == 0 &)], HermitianMatrixQ[m, SameTest -> (Simplify[#1 - #2] == 0 &)], AntihermitianMatrixQ[m, SameTest -> (Simplify[#1 - #2] == 0 &)]} $\endgroup$
    – chuy
    May 7, 2015 at 22:16
  • 2
    $\begingroup$ Indeed there is something certainly amiss. See this: f = (Print[Equal[##]]; Equal[##]) &; AntihermitianMatrixQ[m, SameTest -> f] as opposed to HermitianMatrixQ[m, SameTest -> f]. $\endgroup$
    – chuy
    May 7, 2015 at 22:30

1 Answer 1


Now fixed in version 10.2.

In[1]:= m = {{0, 1}, {-1, 0}};

In[2]:= {AntihermitianMatrixQ[m], HermitianMatrixQ[m], AntihermitianMatrixQ[m]} 

Out[2]= {True, False, True}

As per the comments, yes, there is information stored in the internal representation of matrices (for example, a symmetry flag) and no, it is not accessible from top level code.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.