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

[Jaroslav Hajek]

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?

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.

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

First, a minor correction: the code is not pure F77, it's a subset of
F90 that I usually use
(though in these functions END DO is perhaps the only extension used).
It should compile with most F77 compilers though (incl. g77).

Normally, Fortran functions coded as "external" get a global name just
like C functions,
typically with some simple name mangling (uniform case, underscore).
Any reasonable platform featuring both Fortran and C compiler (which
is necessary for Octave) is virtually bound to have the name mangling,
otherwise Fortran runtime library would necessarily clash with C's, so
that sort of encapsulates all external Fortran routines in a "Fortran
namespace".

Further, it's possible to put Fortran subroutines into a module, which
is a Fortran equivalent to namespace. This forces additional mangling
(module_MP_procedure in gfortran),
but introduces more portability threats, as the rule is certainly
different for different compilers
(while the underscore appending is almost a standard).
So I guess that it's better to go with the current approach that
essentially prevents clashing
C/Fortran names.

"Fortran is not dead, it's just been pushed to a special purpose language."

> jwe
>



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