[Rd] From .Fortran to .Call?

[Balasubramanian Narasimhan]

Also, just came to know about dotcall64::.C64() (on CRAN) which allows 
for Fortran to be called using .Call().

-Naras

On 12/23/20 8:34 AM, Balasubramanian Narasimhan wrote:
> I think it should be pretty easy to fix up SUtools to use the .Call 
> instead of .Fortran following along the lines of
>
> https://github.com/wrathematics/Romp
>
> I too deal with a lot of f77 and so I will most likely finish it 
> before the new year, if not earlier. (Would welcome testers besides 
> myself.)
>
> Incidentally, any idea of what the performance hit is, quantitatively? 
> I confess I never paid attention to it myself as most Fortran code I 
> use seems pretty fast, i.e. glmnet.
>
> -Naras
>
>
> On 12/23/20 3:57 AM, Koenker, Roger W 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 using 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
>>> <naras using 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" <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
>>>> https://urldefense.com/v3/__https://stat.ethz.ch/mailman/listinfo/r-devel__;!!DZ3fjg!s1-ihrZ9DPUtXpxdIpJPA1VedpZFt12Ahmn4CycOmile_uSahFZnJPn_5KPIr_nqkqg$ 
>>>>
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel