On 2020-12-19 18:04, Koenker, Roger W wrote:
There are comments in various places, including R-extensions §5.4 suggesting
that .Fortran is (nearly)
deprecated
This scares me somewhat: Where in §5.4 do you find that suggestion? My
package eha is built upon a stand-alone Fortran 77 program from the
early eighties (emanating from an appendix in [1]) and has served me
well over the years, I see no reason at all to switch to .Call for that
old stuff. But of course, if .Fortran will be deprecated ... Can someone
confirm if, and if so when, that will happen?
Regarding speed, as I understand it, it is a question of making many
(short) calls to .Fortran for solving one problem. If you make only one
or just a few calls to .Fortran (the case in eha), no problem.
[1] Kalbfleisch & Prentice (1980). The Statistical Analysis of Failure
Time Data.
Göran Broström
: 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@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
