[Rd] From .Fortran to .Call?

Bill Dunlap w||||@mwdun|@p @end|ng |rom gm@||@com
Sat Dec 19 18:31:56 CET 2020


To make C prototypes for routines defined in a *.f file you can use
gfortran's -fc-prototypes-external flag.  You still have to convert 'name_'
to 'F77_NAME(name).

bill using Bill-T490:~/packages/quantreg/src$ gfortran -fc-prototypes-external
-fsyntax-only boot.f
... [elided defs of complex types] ...
/* Prototypes for external procedures generated from boot.f
   by GNU Fortran (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0.

   Use of this interface is discouraged, consider using the
   BIND(C) feature of standard Fortran instead.  */

void pwy_ (int *m, int *n, int *k, int *m5, int *n2, double *a, double *c,
double *b, double *t, double *toler, int *ift, double *x, double *e, int
*s, double *wa, double *wb);
void xys_ (int *mofn, int *m, int *n, int *k, int *mofn5, int *n2, double
*a, double *b, double *tau, double *toler, int *ift, double *x, double *e,
int *s, double *wa, double *wb, double *aa, double *bb, int *ss);
void wxy_ (int *m, int *n, int *k, int *m5, int *n2, double *a, double *b,
double *tau, double *toler, int *ift, double *x, double *e, int *s, double
*wa, double *wb, double *aa, double *bb, double *w);

#ifdef __cplusplus
}
#endif
bill using Bill-T490:~/packages/quantreg/src$ gfortran --version
GNU Fortran (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

On Sat, Dec 19, 2020 at 9:05 AM Koenker, Roger W <rkoenker using illinois.edu>
wrote:

> There are comments in various places, including R-extensions §5.4
> suggesting that .Fortran is (nearly)
> deprecated and hinting that use of .Call is more efficient and now
> preferred for packages.  I understand
> and greatly appreciate its use with dyn.load() and R CMD SHLIB for
> development workflow.
> In an effort to modernize my quantreg package I wanted to solicit some
> advice
> about whether it was worthwhile to move away from .Fortran, and if so how
> this
> might be most expeditiously carried out.
>
> As things currently stand my src directory has, in addition to couple
> dozen .f
> files, a file called quantreg_init.c that contains
>
> #include <R_ext/RS.h>
> #include <stdlib.h> // for NULL
> #include <R_ext/Rdynload.h>
>
> /* .Fortran calls */
> extern void F77_NAME(brutpow)(void *, void *, void *, void *, void *, void
> *, void *, void *, void *, void *, void *, void *, void *, void *);
> extern void F77_NAME(combin)(void *, void *, void *, void *, void *, void
> *, void *);
> extern void F77_NAME(crqf)(void *, void *, void *, void *, void *, void *,
> void *, void *, void *, void *, void *, void *, void *, void *, void *,
> void *, void *, void *, void *, void *, void *, void *, void *, void *,
> void *, void *);
>
>>
> static const R_FortranMethodDef FortranEntries[] = {
>     {"brutpow",   (DL_FUNC) &F77_NAME(brutpow),   14},
>     {"combin",    (DL_FUNC) &F77_NAME(combin),     7},
>     {"crqf",      (DL_FUNC) &F77_NAME(crqf),      26},
>
> ...
>
> void R_init_quantreg(DllInfo *dll)
> {
>     R_registerRoutines(dll, CEntries, NULL, FortranEntries, NULL);
>     R_useDynamicSymbols(dll, FALSE);
> }
> This was originally setup by an experienced R person in about 2006, but has
> always been rather opaque to me; I just follow the template to add fortran
> functions.  My questions are:  what would I need to do beyond replacing
> .Fortran calls by .Call in my R code?  And would it help? Obviously, what
> I’m dreading is being told that all those “void”s would have to be
> specified
> more explicitly even though they are already specified in the fortran.  My
> willingness to
> embarrass myself by writing this message was triggered by comparing
> timings of a prototype function in R and its fortranization in which the
> prototype was actually faster.  Thanks in advance for any suggestions.
>
>
>
>
>
>
>
>
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]



More information about the R-devel mailing list