octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Bateman
Subject: Re: [OctDev] linear-algebra: new QR updating functions
Date: Tue, 19 Feb 2008 21:44:03 +0100
User-agent: Thunderbird 2.0.0.6 (X11/20070914)

John W. Eaton 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.

Well the F77 wrapper makes the DEFUNs almost one liners... If we move
the lapack/blas wrapper code from F77 to C++ it'd be a bit longer, maybe
30 lines or so per function. Encapsulating them in the Matrix and
ComplexMatrix class would be fairly trivial.

> 
> | John, we should include these functions.
> 
> Where can I look at them?  I'm not on the octave-dev list.

You can either check out the octave-forge SVN or look at them on the web
interface at

http://octave.svn.sourceforge.net/viewvc/octave/trunk/octave-forge/main/linear-algebra/src/


> | Are you happy with the F77
> | wrapper to blas/lapack function to have only a single F77 function in
> | the Octave C++ wrapper or should that be modified to use a pure C++ wrapper?
> 
> Is there any way to put f77 functions inside a namespace?

That's not the way the rest of the F77 code in Octave is used.. In any
case Jaroslav responded that the reason he wanted to keep them in F77 is
so that he can use them elsewhere, which is prefectly valid, and so if
we want to rely on him to continue to support the code better that the
wrapper stays in F77 and the wrapper itself goes somewhere in libcruft.

Regards
David



reply via email to

[Prev in Thread] Current Thread [Next in Thread]