[Rd] From .Fortran to .Call?
@vr@h@m@@d|er @end|ng |rom gm@||@com
Wed Dec 23 02:11:32 CET 2020
I used .Call instead of .Fortran in the Delaporte package . What
helped me out a lot was Drew Schmidt's Romp examples and descriptions
. If you are more comfortable with the older Fortran interface,
Tomasz Kalinowski has a package which uses Fortran 2018 more
efficiently . I haven't tried this last in practice, however.
Hope that helps,
On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
<naras using stanford.edu> wrote:
> To deal with such Fortran issues in several packages I deal with, I
> wrote the SUtools package (https://github.com/bnaras/SUtools) that you
> can try. The current version generates the registration assuming
> implicit Fortran naming conventions though. (I've been meaning to
> upgrade it to use the gfortran -fc-prototypes-external flag which should
> be easy; I might just finish that during these holidays.)
> There's a vignette as well:
> On 12/19/20 9:53 AM, Ivan Krylov wrote:
> > On Sat, 19 Dec 2020 17:04:59 +0000
> > "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.
> > My understanding of §5.4 and 5.5 is that explicit routine registration
> > is what's important for efficiency, and your package already does that
> > (i.e. calls R_registerRoutines()). The only two things left to add
> > would be types (REALSXP/INTSXP/...) and styles (R_ARG_IN,
> > R_ARG_OUT/...) of the arguments of each subroutine.
> > Switching to .Call makes sense if you want to change the interface of
> > your native subroutines to accept arbitrary heavily structured SEXPs
> > (and switching to .External could be useful if you wanted to play with
> > evaluation of the arguments).
> R-devel using r-project.org mailing list
More information about the R-devel