Avraham Adler
2017-Jun-06 20:27 UTC
[Rd] Philosophy behind converting Fortran to C for use in R
Hello. This is not a question about a bug or even best practices; rather I'm trying to understand the philosophy or theory as to why certain portions of the R codebase are written as they are. If this question is better posed elsewhere, please point me in the proper direction. In the thread about the issues with the Tukey line, Martin said [1]:> when this topic came up last (for me) in Dec. 2014, I did spend about 2 days work (or more?) > to get the FORTRAN code from the 1981 - book (which is abbreviated the "ABC of EDA") > from a somewhat useful OCR scan into compilable Fortran code and then f2c'ed, > wrote an R interface function found problems?I have seen this in the R source code and elsewhere, that native Fortran is converted to C via f2c and then run as C within R. This is notwithstanding R's ability to use Fortran, either directly through .Fortran() [2] or via .Call() using simple helper C-wrappers [3]. I'm curious as to the reason. Is it because much of the code was written before Fortran 90 compilers were freely available? Does it help with maintenance or make debugging easier? Is it faster or more likely to compile cleanly? Thank you, Avi [1] https://stat.ethz.ch/pipermail/r-devel/2017-May/074363.html [2] Such as kmeans does for the Hartigan-Wong method in the stats package [2] Such as the mvtnorm package does
William Dunlap
2017-Jun-06 21:34 UTC
[Rd] Philosophy behind converting Fortran to C for use in R
Here are three reasons for converting Fortran code, especially older Fortran code, to C: 1. The C-Fortran interface is not standardized. Various Fortran compilers pass logical and character arguments in various ways. Various Fortran compilers mangle function and common block names in variousl ways. You can avoid that problem by restricting R to using a certain Fortran compiler, but that can make porting R to a new platform difficult. 2. By default, variables in Fortran routines are not allocated on the stack, but are statically allocated, making recursion hard. 3. New CS graduates tend not to know Fortran. (There are good reasons for not translating as well, risk and time being the main ones.) Bill Dunlap TIBCO Software wdunlap tibco.com On Tue, Jun 6, 2017 at 1:27 PM, Avraham Adler <avraham.adler at gmail.com> wrote:> Hello. > > This is not a question about a bug or even best practices; rather I'm > trying to understand the philosophy or theory as to why certain > portions of the R codebase are written as they are. If this question > is better posed elsewhere, please point me in the proper direction. > > In the thread about the issues with the Tukey line, Martin said [1]: > > > when this topic came up last (for me) in Dec. 2014, I did spend about 2 > days work (or more?) > > to get the FORTRAN code from the 1981 - book (which is abbreviated the > "ABC of EDA") > > from a somewhat useful OCR scan into compilable Fortran code and then > f2c'ed, > > wrote an R interface function found problems? > > I have seen this in the R source code and elsewhere, that native > Fortran is converted to C via f2c and then run as C within R. This is > notwithstanding R's ability to use Fortran, either directly through > .Fortran() [2] or via .Call() using simple helper C-wrappers [3]. > > I'm curious as to the reason. Is it because much of the code was > written before Fortran 90 compilers were freely available? Does it > help with maintenance or make debugging easier? Is it faster or more > likely to compile cleanly? > > Thank you, > > Avi > > [1] https://stat.ethz.ch/pipermail/r-devel/2017-May/074363.html > [2] Such as kmeans does for the Hartigan-Wong method in the stats package > [2] Such as the mvtnorm package does > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel[[alternative HTML version deleted]]
Martyn Byng
2017-Jun-07 07:07 UTC
[Rd] Philosophy behind converting Fortran to C for use in R
Hi, Just a quick comment on (1). The C-Fortran interface has been standardized since Fortran 2003. However, it does require the Fortran interface that is being called from C to have been written with C operability in mind as specific C interoperable types etc. must be used. Trying to call a Fortran interface that hasn't been written using C interoperable types still suffers from the issues that Bill describes. Martyn -----Original Message----- From: R-devel [mailto:r-devel-bounces at r-project.org] On Behalf Of William Dunlap via R-devel Sent: 06 June 2017 22:34 To: Avraham Adler <avraham.adler at gmail.com> Cc: R-devel <r-devel at r-project.org> Subject: Re: [Rd] Philosophy behind converting Fortran to C for use in R Here are three reasons for converting Fortran code, especially older Fortran code, to C: 1. The C-Fortran interface is not standardized. Various Fortran compilers pass logical and character arguments in various ways. Various Fortran compilers mangle function and common block names in variousl ways. You can avoid that problem by restricting R to using a certain Fortran compiler, but that can make porting R to a new platform difficult. 2. By default, variables in Fortran routines are not allocated on the stack, but are statically allocated, making recursion hard. 3. New CS graduates tend not to know Fortran. (There are good reasons for not translating as well, risk and time being the main ones.) Bill Dunlap TIBCO Software wdunlap tibco.com On Tue, Jun 6, 2017 at 1:27 PM, Avraham Adler <avraham.adler at gmail.com> wrote:> Hello. > > This is not a question about a bug or even best practices; rather I'm > trying to understand the philosophy or theory as to why certain > portions of the R codebase are written as they are. If this question > is better posed elsewhere, please point me in the proper direction. > > In the thread about the issues with the Tukey line, Martin said [1]: > > > when this topic came up last (for me) in Dec. 2014, I did spend about 2 > days work (or more?) > > to get the FORTRAN code from the 1981 - book (which is abbreviated the > "ABC of EDA") > > from a somewhat useful OCR scan into compilable Fortran code and then > f2c'ed, > > wrote an R interface function found problems? > > I have seen this in the R source code and elsewhere, that native > Fortran is converted to C via f2c and then run as C within R. This is > notwithstanding R's ability to use Fortran, either directly through > .Fortran() [2] or via .Call() using simple helper C-wrappers [3]. > > I'm curious as to the reason. Is it because much of the code was > written before Fortran 90 compilers were freely available? Does it > help with maintenance or make debugging easier? Is it faster or more > likely to compile cleanly? > > Thank you, > > Avi > > [1] https://stat.ethz.ch/pipermail/r-devel/2017-May/074363.html > [2] Such as kmeans does for the Hartigan-Wong method in the stats package > [2] Such as the mvtnorm package does > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel[[alternative HTML version deleted]] ______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel ________________________________________________________________________ This e-mail has been scanned for all viruses by Star. ________________________________________________________________________
Apparently Analagous Threads
- Philosophy behind converting Fortran to C for use in R
- Notes on building a gcc toolchain for Rtools (but not multilib)
- Notes on building a gcc toolchain for Rtools (but not multilib)
- Unexpected EOF in R-patched_2017-01-30
- Has the changelog for R-devel and R-patched moved?