[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OctDev] linear-algebra: new QR updating functions
From: |
Michael Goffioul |
Subject: |
Re: [OctDev] linear-algebra: new QR updating functions |
Date: |
Wed, 20 Feb 2008 09:59:25 +0100 |
On Feb 20, 2008 9:06 AM, Jaroslav Hajek <address@hidden> wrote:
> > | 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.
If this gets included in octave, please make sure it would also work
with f2c (otherwise, I'll be unable to compile it).
Michael.