From avraham.adler at gmail.com  Tue Jun  6 22:27:23 2017
From: avraham.adler at gmail.com (Avraham Adler)
Date: Tue, 6 Jun 2017 16:27:23 -0400
Subject: [Rd] Philosophy behind converting Fortran to C for use in R
Message-ID: <CAL6gwn+ecV5vU+acf89icX6zYb519M2TbXQAFjyBqQ4MOQqkJA@mail.gmail.com>

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



[Rd] Philosophy behind converting Fortran to C for use in R
Avraham Adler