Skip to content
Prev 248903 / 398503 Next

Positive Definite Matrix

> follows: 

    > 1.  Give up on Cholesky factors unless you have a
    > matrix you know must be symmetric and strictly positive
    > definite.  (I seem to recall having had problems with chol
    > even with matrices that were theoretically positive or
    > nonnegative definite but were not because of round off.
    > However, I can't produce an example right now, so I'm not
    > sure of that.)

(other respondents to this thread mentioned such scenarios, they
 are not at all uncommon)

    >              2.  If you must test whether a matrix is
    > summetric, try all.equal(A, t(A)).  From the discussion, I
    > had the impression that this might not always do what you
    > want, but it should be better than all(A==t(A)).  It is
    > better still to decide from theory whether the matrix
    > should be symmetric.

Hmm, yes: Exactly for this reason,  R  has had a *generic* function

 isSymmetric()
 -------------
for quite a while:
In "base R" it uses all.equal() {but with tightened default tolerance},
but e.g., in the Matrix package,
it "decides from theory" ---  the Matrix package containing
quite a few Matrix classes that are symmetric "by definition".

So my recommendation really is to use  isSymmetric().


    >              3.  Work with the Ae = eigen(A,
    > symmetric=TRUE) or eigen((A+t(A))/2, symmetric=TRUE).
    > From here, Ae$values <- pmax(Ae$values, 0) ensures that A
    > will be positive semidefinite (aka nonnegative definite).
    > If it must be positive definite, use Ae$values <-
    > pmax(Ae$values, eps), with eps>0 chosen to make it as
    > positive definite as you want.

hmm, almost: The above trick has been the origin and basic
building block of posdefify() from the sfsmisc package,
mentioned earlier in this thread. 
But I have mentioned that there are much better algorithms
nowadays, and  Matrix::nearPD()  uses one of them .. actually
with variations on the theme  aka optional arguments.



    >              4.  To the maximum extent feasible, work with
    > Ae, not A.  Prof. Ripley noted, "You can then work with
    > [this] factorization to ensure that (for example)
    > variances are always non-negative because they are always
    > computed as sums of squares.  This sort of thing is done
    > in many of the multivariate analysis calculations in R
    > (e.g. cmdscale) and in well-designed packages."

yes, or---as mentioned by Prof Ripley as well---compute a
square root of the matrix {e.g. via the eigen() decomposition
with modified eigenvalues} and work with that.
Unfortunately, in quite a few situations you just need a
pos.def. matrix to be passed to another R function  as 
cov / cor matrix, and their,  nearPD()  comes very handy.


    >        Hope this helps.  Spencer

It did, thank you,
Martin
> On 1/30/2011 3:02 AM, Alex Smith wrote:
>> Thank you for all your input but I'm afraid I dont know
    >> what the final conclusion is. I will have to check the
    >> the eigenvalues if any are negative.  Why would setting
    >> them to zero make a difference? Sorry to drag this on.
    >> 
    >> Thanks
    >> 
    >> On Sat, Jan 29, 2011 at 9:00 PM, Prof Brian
>> Ripley<ripley at stats.ox.ac.uk>wrote:
>>
>>> On Sat, 29 Jan 2011, David Winsemius wrote:
>>> 
    >>>
>>>> On Jan 29, 2011, at 12:17 PM, Prof Brian Ripley wrote:
>>>>
>>>> On Sat, 29 Jan 2011, David Winsemius wrote:
>>>>>
>>>>>>
>>>>>>>> Dear David and Alex, I'd be a little careful about
    >>>>>>>> testing exact equality as in all(M == t(M) and
    >>>>>>>> careful as well about a test such as
    >>>>>>>> all(eigen(M)$values> 0) since real arithmetic on a
    >>>>>>>> computer can't be counted on to be exact.
    >>>>>>>> 
    >>>>>>> Which was why I pointed to that thread from 2005 and
    >>>>>>> the existing work that had been put into
    >>>>>>> packages. If you want to substitute all.equal for
    >>>>>>> all, there might be fewer numerical false alarms,
    >>>>>>> but I would think there could be other potential
    >>>>>>> problems that might deserve warnings.
    >>>>>>>
>>>>>>> is also a
>>>>>>> Description :
>>>>>>> one."
    >>>>>> 
    >>>>> But again, that is not usually what you want.  There
    >>>>> is no guarantee that the result is positive-definite
    >>>>> enough that the Cholesky decomposition will work.
    >>>>> 
    >>>> I don't see a Cholesky decomposition method being used
    >>>> in that function.  It appears to my reading to be
    >>>> following what would be called an eigendecomposition.
    >>>> 
    >>> Correct, but my point is that one does not usually want
    >>> a
    >>> 
    >>> "close" positive definite one
    >>> 
    >>> but a 'square root'.
    >>> 
    >>> 
    >>> 
    >>>> --