[R] Using .Fortran in R - how can I use file i/o flexibly OR arrays of variable length as arguments?

Jeff Newmiller jdnewm|| @end|ng |rom dcn@d@v|@@c@@u@
Sun Feb 6 00:37:47 CET 2022


This really does belong on r-package-devel. Do reply there if at all.

As regards your whining about dynamic memory... differences of opinion about heap memory handling are pervasive between languages and even between libraries used within the same language, and Fortran was used for many decades without dynamic memory options at all. So this situation is normal, and R can't force other code to conform to its requirements. We live in a world of multi-gigabyte RAM and 100Mflop computation resources... pre-allocate more than you need and fail if it isn't enough. Or figure out a way to provide an estimate of the needed memory as Ivan suggested. Or split your computations into an early (don't know yet but are figuring out out) and late phase (when you do know and can pass in sufficient allocated memory from R).

On February 5, 2022 1:41:02 AM PST, Peter Green <mapjg using bristol.ac.uk> wrote:
>Thank you, Ivan, it's reassuring in a way to learn from your reply that 
>I am not missing something very obvious.
>
>It's unfortunate that a computation that could be done cleanly, using 
>dynamic allocation of memory, within either R or Fortran separately, 
>cannot be split between the two in a way that is optimal for the 
>capabilities of each language, because of the .Fortran bottleneck. I 
>wondered whether you (or anyone) thought there was a way to do this 
>using C wrapper routines in some way? Unfortunately, the ultimate size 
>of the output is something the algorithm would only learn very late in 
>the computation, so pre-calculating that size is not a practical option 
>(else indeed I would do that within R before use of .Fortran).
>
>Any thought on the other route I suggested, that is, binary file i/o 
>from with the Fortran code (e.g. full use of the connections 
>functionality), again perhaps via C?
>
>Although I mentioned CRAN, that was really just to stress I wanted a 
>platform-independent solution ideally.
>
>Peter Green
>
>On 05/02/2022 08:09, Ivan Krylov wrote:
>> On Fri, 4 Feb 2022 10:21:11 +0000
>> Peter Green <mapjg using bristol.ac.uk> wrote:
>>
>>> the output I want to return to R is copious, and variable in length,
>>> the length being computed within the Fortran code (it is a
>>> variable-dimension simulation)
>> Is there a way to separate the calculation of the output size from the
>> rest of the subroutine? If yes, the simplest option would be to pass
>> pre-allocated vectors to the .Fortran() call.
>>
>> Unfortunately, .Fortran() is not expressive enough for more complicated
>> use cases. Memory that you intend to return to R must be allocated
>> using its own allocator/garbage collector system, which (like any other
>> call into R from user code) may longjmp() away from your functions on
>> interrupt, error or allocation failure, abandoning any resources the
>> garbage collector doesn't know about. In turn, this requires the use of
>> C and the PROTECT() macro. In theory, you could use Fortran 2003 "C
>> interoperability" to call C entry points, but I expect that to be very
>> inconvenient (at least due to the lack of CPP macros).
>>
>> Since you mention CRAN checks, this might be a better question for
>> <r-package-devel using r-project.org>, not R-help.
>>
>
>______________________________________________
>R-help using r-project.org mailing list -- To UNSUBSCRIBE and more, see
>https://stat.ethz.ch/mailman/listinfo/r-help
>PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
>and provide commented, minimal, self-contained, reproducible code.

-- 
Sent from my phone. Please excuse my brevity.



More information about the R-help mailing list