Fortran vs C, easing using Fortran

[Prof Brian D Ripley]

On 10 Apr 1999, Douglas Bates wrote:

> >>>>> "Ross" == Ross Ihaka <ihaka@stat.auckland.ac.nz> writes:
> 
>   Ross> To follow up the "eigen" issue.  What should our position on
>   Ross> translating Fortran into C be?  Should we leave as much code
>   Ross> as possible in Fortran or should we move it to C as much as
>   Ross> possible?
> 
> I can think of three different sets of circumstances:
>  a) creating new code: This one is obvious, just say "no" to Fortran.
>  b) enhancing existing code: For something small do the automatic
>       translation to C with f2c then modify the C sources and regard
>       those as the definitive version.  For a big Fortran routine, try
>       to write a C wrapper around it and make modifications in the
>       wrapper. 
>  c) using established code without modification (e.g. Eispack, Linpack):
>       Regard the Fortran sources as the definitive version and don't
>       translate.
> 
> Now that g77 is available and reasonably stable, a lot of the
> motivation for using f2c is gone.  There are still the messy linkage
> issues when calling Fortran from C but most of those are now resolved
> by the configure script.  Passing character strings, etc. will
> continue to be problematic but most of the legacy Fortran code we
> would use will be strictly numerical routines with, we hope,
> comparatively simple calling sequences.  (Lapack is an exception in
> that it uses strings to declare options but we aren't using Lapack.)

[A long reply: I am much-bitten here!]

1) In my experience there are problems with error reporting via strings in
such Fortran code, as I found in loess (and found more easily in less
complicated packages). I wrote a two-step interface (in Fortran find the
string length, pass that and string back to C), and perhaps we should
set up warning and error subroutines to be called from Fortran to
standardize this that package writers/porters could use.


2) My motivation would be to use Fortran wherever it already exists. In the
world of scientific computing Fortran has been king and the effort in
compiler development has gone into efficient Fortran compilers with godd
optimizers. So on a Sun or DEC Alpha (and probably SGI) the original
Fortran used to run appreciably faster than the C translation (using the
native compilers), and although the gap has closed I think it is still
quite noticeable.  In my experience R can't afford that price. This may not
be an issue on Linux/Windows, but I expect is on Sun/DEC/SGI/HP.

BTW, I think that means that Doug's `just say "no" to Fortran' is not
obviously true if performance matters. This is likely to especially true if
single-precision calculations will do the job. (And, yes, I know about
Intel hardware but I don't see the need to slow a Sparc or Alpha FP unit
down to Intel speeds, especially older ones. I also know how to make C do
efficient float calculations using float libraries on Sparc, but that sort
of thing is a nightmare to configure portably, and also to link into S or 
R. It happens for free in Fortran.)


3) The problem is finding the external calls from Fortran code. In the base
code this should be not problem now we use the Fortran front-end to link.  
I have problems with quite a few packages that use Fortran, and have
translated some code myself just to avoid those. (It was a big problem in
the first release of MASS software for S-PLUS, and we removed all the 
Fortran to save ourselves the hastle of `it won't work on my XYZ system'
reports. We never made the Fortran work on HPs, whose Fortran name space
clashes with the C one, and it seemed that S had already grabbed some
critical symbols as C ones.)

I think in R we can do better than at present, if only I knew
exactly how. One idea is to have (effectively) a `hints' file that
configure uses to add a base set of libraries to FLIBS, but on Solaris
at least, using the Fortran command (f77 or g77) to link a dynamic library
does the job.  For linking with ld the base FLIBS would need to be

-lF77 -lM77 -lV77 -lsunmath -lm

_if_ f77 is used.  How viable is `use FC to link' on other platforms?

And to come back to beating a drum, if the dlopen option were RTLD_NOW
not RTLD_LAZY, these things would be easier to check. People keep sending
packages to CRAN that are incomplete (mclust seems to be now) and with
RTLD_NOW this is _much_ more likely to be noticed. Can we re-consider?

Brian

-- 
Brian D. Ripley,                  ripley@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272860 (secr)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !)  To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._