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

[Carlo de Falco]

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

Hi,
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, 
e.g.:

dbleCHOL.[h|cc]
floatCHOL.[h|cc]
CmplxCHOL.[h|cc]
fCmplxCHOL.[h|cc]

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:

  <http://savannah.gnu.org/bugs/?34850>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/