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? 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 ------------------------------------------------------------------------- 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
