[Rd] From .Fortran to .Call?

[Göran Broström]

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 using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>