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/