As the proverbial naive R (ab)user I?m left wondering:
o if I updated my quantreg_init.c file in accordance with Bill?s
suggestion could I
then simply change my .Fortran calls to .Call?
No. .Call(C_func, arg1, arg2) expects C_func's arguments to all be SEXP*
(pointers to R objects), never the double* or the like that .Fortran
expects.
-Bill
On Wed, Dec 23, 2020 at 3:58 AM Koenker, Roger W <rkoenker at illinois.edu>
wrote:
Thanks to all and best wishes for a better 2021.
Unfortunately I remain somewhat confused:
o Bill reveals an elegant way to get from my rudimentary
registration setup to
one that would explicitly type the C interface functions,
o Ivan seems to suggest that there would be no performance gain
from doing this.
o Naras?s pcLasso package does use the explicit C typing, but
then uses .Fortran
not .Call.
o Avi uses .Call and cites the Romp package
https://github.com/wrathematics/Romp
where it is asserted that "there is a (nearly) deprecated
interface .Fortran() which you
should not use due to its large performance overhead.?
As the proverbial naive R (ab)user I?m left wondering:
o if I updated my quantreg_init.c file in accordance with Bill?s
suggestion could I
then simply change my .Fortran calls to .Call?
o and if so, do I need to include ALL the fortran subroutines in
my src directory
or only the ones called from R?
o and in either case could I really expect to see a significant
performance gain?
Finally, perhaps I should stipulate that my fortran is strictly f77, so
no modern features
are in play, indeed most of the code is originally written in ratfor,
Brian Kernighan?s
dialect from ancient times at Bell Labs.
Again, thanks to all for any advice,
Roger
On Dec 23, 2020, at 1:11 AM, Avraham Adler <avraham.adler at gmail.com>
Hello, Ivan.
I used .Call instead of .Fortran in the Delaporte package [1]. What
helped me out a lot was Drew Schmidt's Romp examples and descriptions
[2]. If you are more comfortable with the older Fortran interface,
Tomasz Kalinowski has a package which uses Fortran 2018 more
efficiently [3]. I haven't tried this last in practice, however.
Hope that helps,
Avi
[1]
Tomasz Kalinowski
On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
<naras at stanford.edu> wrote:
To deal with such Fortran issues in several packages I deal with, I
wrote the SUtools package (
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
be easy; I might just finish that during these holidays.)
There's a vignette as well:
-Naras
On 12/19/20 9:53 AM, Ivan Krylov wrote:
On Sat, 19 Dec 2020 17:04:59 +0000
"Koenker, Roger W" <rkoenker at 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).