On Feb 20, 2008 9:57 AM, John W. Eaton <[EMAIL PROTECTED]> wrote: > On 20-Feb-2008, Jaroslav Hajek wrote: > > | On Feb 19, 2008 7:46 PM, John W. Eaton <[EMAIL PROTECTED]> 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 ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Octave-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/octave-dev
