Given Mark's description, this does indeed sound like a "bug" or at least an
annoying feature. The problem, of course, is that Stata doesn't "know" that the
matrix in question is (supposed to be) symmetric. I'm not sure it's a great
idea to use a procedure that forces symmetry, however, because one might be
tempted to use the procedure in situations that don't guarantee (in principle)
that a matrix is symmetric. This is not Mark's situation, but I can imagine one
in which subtle programming issues obscure the problem and an incorrect use of
something like syminv2 could lead to difficulties. And wouldn't we also need a
cholesky2 command?
Instead, I'd suggest that Stata develop an internally created and maintained
property for matrices that indicates whether or not it is symmetric. Perhaps
this is already being done for diagonal matrices. This property would "know"
that the result of particular matrix expressions should create a symmetric
matrix and enforce this by whatever internal operations are necessary. For
example, Stata should know that if S is symmetric, then X*S*X' is also
symmetric. If S had a property that indicated its symmetric nature, then Stata
could perform the appropriate calculations/manipulations to ensure that the
result of this expression is also symmetric, and assign it the symmetric
property as well.
Admittedly, this would require re-tooling Stata. But it would result in a
change that was transparent to programmers and users without having to add yet
another special purpose command or two.
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Mark Schaffer
> Sent: Monday, June 09, 2003 4:19 PM
> To: Statalist
> Cc: Mark Schaffer
> Subject: st: Matrix inversion "bug"
>
>
> Dear Statalisters:
>
> Every now and then I encounter a matrix inversion "bug" in Stata. It
> cropped up yet again last week when an ivreg2 user wrote to me, and I
> finally decided to see what my fellow Statalisters think of it.
>
> Say we have a matrix M which is calculated as X*S*X'. S is symmetric and
> so is M. We want to invert M and so the best thing to do is to use
> -syminv-. The Stata programming manual tells us to use -syminv- instead
> of -inv- wherever possible.
>
> The problem is this. Although M is guaranteed to be symmetric in
> principle, it is not guaranteed to be symmetric in practice. Tiny rounding
> errors can arise when Stata multiplies matrices. Once in a while, M will
> be very slightly non-symmetric, but when it is, -syminv- will exit with an
> error.
>
> When I first encountered this, I wrote to Stata Technical Support, and I
> received a very helpful and simple fix: prior to the call to syminv, simply
> do the following:
>
> mat M = (M+M')/2
>
> This makes the matrix symmetric. Works, no problem. But...
>
> Arguably, this is just a fix for what is really a Stata bug. Ought it be
> possible for Stata's code to recognise when the result of a matrix
> multiplication is supposed to be a symmetric matrix?
>
> Whether or not this should be called a "bug", it may still be the case that
> it's not possible for our friends at Stata Corp to fix it. If so, then
> there are several possibilities:
>
> (1) Prior to using -syminv-, we should always (?) symmetrize the matrix we
> want to invert using the code fragment above.
>
> (2) Any (?) time we call -syminv-, we should use -capture-. If the
> inversion using -syminv- fails, we should call -inv-.
>
> (3) Neither of the above is very pretty. An alternative is to ask our
> Stata Corp friends to, say, add a variant of the -syminv- function, say
> -syminv2-. This function would automatically symmetrize a square matrix
> before inverting it.
>
> What do you think?
>
> --Mark
>
> ________________________________________________________________
>
> DISCLAIMER:
>
> This e-mail and any files transmitted with it are confidential
> and intended solely for the use of the individual or entity to
> whom it is addressed. If you are not the intended recipient
> you are prohibited from using any of the information contained
> in this e-mail. In such a case, please destroy all copies in
> your possession and notify the sender by reply e-mail. Heriot
> Watt University does not accept liability or responsibility
> for changes made to this e-mail after it was sent, or for
> viruses transmitted through this e-mail. Opinions, comments,
> conclusions and other information in this e-mail that do not
> relate to the official business of Heriot Watt University are
> not endorsed by it.
> ________________________________________________________________
> *
> * For searches and help try:
> * http://www.stata.com/support/faqs/res/findit.html
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
>
>
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
