[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #34850] Behaviour of chol(a,'lower')

From: Carlo de Falco
Subject: [Octave-bug-tracker] [bug #34850] Behaviour of chol(a,'lower')
Date: Sun, 20 Nov 2011 18:33:43 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20100101 Firefox/8.0

Follow-up Comment #5, bug #34850 (project octave):

thanks for your feedback

>> I know nothing of Octave internals, but it seems to me that the 
>> most logical way would be to propagate the "lower" choice down 
>> to LAPACK; this also saves the transpose (which takes time).

Indeed that would be cleaner, but it requires changing quite 
a large number of files, accounting for all possible base types, 


and so on ...

As I said I have to think a little bit myself about how to do that 
without too much code duplication and it will take time, that's why I'm 
proposing a temporary patch.

>> I have trouble now looking at the patch something is worng with 
>> the connection, but about a hour ago I got a glimpse, and I 
>> remember you are calling X.transpose() for complex data; 
>> in that case you want to have the conjugate transpose to feed ZPOTRF.

You are probably right on this one, X.hermitian () would be correct here.

But I think this shows another problem with the current implementation: 
what chol.cc currently does is call xPOTRF with UPLO = 'U' and then 
return the transpose of the factor,
I think for x = [c|z] it should actually also return the hermitian, 
is this correct? could you check if chol ( ... ,'lower') currently 
works as you expect for complex types?


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]