Re: [OctDev] linear-algebra: new QR updating functions

[Jaroslav Hajek]

On Feb 20, 2008 9:57 AM, John W. Eaton <address@hidden> wrote:
> On 20-Feb-2008, Jaroslav Hajek wrote:
>
> | On Feb 19, 2008 7:46 PM, John W. Eaton <address@hidden> wrote:
> | > On 19-Feb-2008, David Bateman wrote:
> | >
> | > | I'd suggest reworking this as a patch against octave, with the F77 code
> | > | in a directory libcruft/qrupdate (or something similar) and the C++
> | > | interfaces in src/DLD-FUNCTIONS.. The Makefile.in files will need to be
> | > | modified appropriately.
> | >
> | > It might also be useful to have a C++ interface in liboctave itself,
> | > so that the DEFUN wrapper is very simple.  I know that there are some
> | > DEFUNs in Octave that have extensive code and even direct calls to f77
> | > functions, but that was not the original intent.  I find it better if
> | > we can keep the DEFUNS as simple wrappers around classes/functions
> | > where most of the work is done outside of the DEFUN.  I haven't seen
> | > the code yet, so maybe you are already doing this.
> | >
> |
> | I think it's possible to add update, insert and delete methods to the QR and
> | ComplexQR classes, along with a new constructor that allows them to be
> | explicitly constructed. Is that what you mean?
>
> Yes, I suppose so.  I wasn't actually thinking so much of the details
> of what the code is doing, just that it is good to have a C++
> interface in liboctave if possible.
>
> | Anyway, your look at DEFUNs surprises me. I think that Octave's ability to 
> write
> | compiled functions against object-oriented internal interface is one
> | of its advantages
> | over Matlab.
>
> I'm not sure we disagree here.  Maybe I wasn't clear.  The reason I
> say that a DEFUN should just be a wrapper around some other code is
> that if it does a lot of calculations, then whatever function it
> performs is not easily accessible to other internal parts of Octave.
> It is much better if the real work is done in a C++ class and the
> DEFUN just wraps it to make it available for the scripting language.
> That way, the functionality is easily available to other internal
> functions in Octave without going through the overhead of
> creating/decoding octave_value_list argument/return lists.  As an
> example, look at src/DLD-FUNCTIONS/qz.cc and src/DLD-FUNCTIONS/qz.cc.
> I'd like to discourage writing new functions in the style of qz.cc and
> encourage more in the style of qr.cc.
>
> jwe
>

Ah, now I understand. You're absolutely right on this.
Is it OK if I rework this as a changeset against current Octave hg snapshot,
include the Fortran sources into libcruft, add corresponding methods to
the QR, ComplexQR, CHOL and ComplexCHOL classes, and then use these
inside the DEFUNs ?


-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz