Re: [eigen] Positive Definitenes?

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/3/4 Gabriel <gabrielvc@xxxxxxxxx>:
> Thanks for your answers, I will check the approaches to check for
> efficiency. This operation would have to be done several times, and I do
> need to solve a matrix equation K x = b, with K the matrix, and b a known
> vector, and this is done a lot of times.
>
> Is there an error handler implemented? In my code this operation is
> performed hundreds of times and I would need to automatize some sort of
> workaround when the matrix is not positive definite. This would signal an
> error in my code, my matrices have to bee p.d. all the time, so I would
> implement something to forget the systems in which p.d. gets "lost".

It's not all-or-nothing: if you try to feed an indefinite matrix to an
algorithm that requires definite matrices, it typically won't be able
to tell you that the matrix is indefinite, instead in many cases it
will just be very inaccurate without being able to reliably report an
error. So, to answer your question, no such error reporting is made by
Eigen, but that's because it's impossible to implement correctly.

Benoit

>
> Gabriel
>
>
>
> On Wed, Mar 3, 2010 at 6:56 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
> wrote:
>>
>> 2010/3/3 Cyril Flaig <cflaig@xxxxxxxxxxx>:
>> > On 2010-03-02 19:27, Benoit Jacob wrote:
>> >> 2010/3/2 Cyril Flaig <cflaig@xxxxxxxxxxx>:
>> >>> The Cholesky decomposition works only if the matrix is positive
>> >>> definite. If the decomposition fails then eigen sets a
>> >>> m_isPositiveDefinite to false, doesn't it?
>> >>>
>> >>> Or is this deprecated and not used in the new version?
>> >>
>> >> This is deprecated indeed.
>> >
>> > As far as I know. The fastest way to determine the postive definitnes is
>> > to check the diagonal if all entries are >=0.
>>
>> This is indeed a necessary condition for positiveness.
>>
>> > If this is true then
>> > attempt a Cholesky decomposition. If it exists then the matrix is
>> > positive definite.
>>
>> The problem with this approach is that it's an all-or-nothing test
>> that one has to perform at the time of the decomposition itself.
>> Making this useful in practice would require us to let the user pass a
>> choice of a threshold at the time of the decomposition itself (so an
>> API change) and even then, that would be pretty bad as, if the user
>> passes a higher threshold, he compromises the accuracy of a subsequent
>> solve(). So this forces a compromise between the invertibility check
>> and the precision of solve().
>>
>> Benoit
>>
>> >
>> > -cyril
>> >
>> >
>>
>>
>
>
>
> --
> ==============
> =  Gabriel Villalobos,
> =  Candidato a Doctor en Ciencias - Física, UN
> =  M.Sc. Physics, Georgia Institute of Technology
> =  Físico, Universidad Nacional de Colombia
> = Tel. Oficina. (571) 3165000 - 13031
> = gvillalobosc@xxxxxxxxxxxxxx
> =  Enamoradamente Casado
> ===============
> = Acuerdos Toltecas:
> = * Hacer siempre y en todo asunto nuestro mejor
> = esfuerzo,
> = * Ser impecable con la palabra
> = * No suponer
> = * No tomarse nada a título personal
> ==============
>
>
>
>