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 <rkoen...@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.ad...@gmail.com>
> wrote:
> >
> > 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]
> https://urldefense.com/v3/__https://CRAN.R-project.org/package=Delaporte__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITBN5NK8$
> > [2]
> https://urldefense.com/v3/__https://github.com/wrathematics/Romp__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPISF5aCYs$
> > [3]
> https://urldefense.com/v3/__https://github.com/t-kalinowski/RFI__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIbwXmXqY$
> >
> > Tomasz Kalinowski
> >
> >
> >
> > On Tue, Dec 22, 2020 at 7:24 PM Balasubramanian Narasimhan
> > <na...@stanford.edu> wrote:
> >>
> >> To deal with such Fortran issues in several packages I deal with, I
> >> wrote the SUtools package (
> https://urldefense.com/v3/__https://github.com/bnaras/SUtools__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIJ5BbDwA$
> ) 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:
> >>
> https://urldefense.com/v3/__https://bnaras.github.io/SUtools/articles/SUtools.html__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPITq9-Quc$
> >>
> >> -Naras
> >>
> >>
> >> On 12/19/20 9:53 AM, Ivan Krylov wrote:
> >>> On Sat, 19 Dec 2020 17:04:59 +0000
> >>> "Koenker, Roger W" <rkoen...@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@r-project.org mailing list
> >>
> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
