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

[John W. Eaton]

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