Fortran vs C, easing using Fortran
Ross Ihaka
ihaka@stat.auckland.ac.nz
Tue, 13 Apr 1999 08:53:57 +1200 (NZST)
On Mon, 12 Apr 1999, Paul Gilbert wrote:
> It seems to me that, at least for application packages, there is a strong
> incentive to avoid both fortran and C. If eventual R, or a new language like
> Omega, are to work in a "Java like" way across platforms, I think both fortran
> and C are problems. Is that not correct?
IMHO: Java is (currently) too slow for production numerical work and I
suspect that this will remain the case for some time. Java gets around
this by providing a way of calling Fortran and C.
I once heard an informed opinion that it would hard to get a language like
S to perform within a factor of 10 of optimized C or Fortran. Most of the
time we can live with a factor of 10, but sometimes ...
There is also the issue of the code base available in Fortran (and to a
lesser extent in C). It's a resource which can't be ignored.
> I realize there is a performance issue, but I don't think it is as serious as it
> was in old versions of Splus. I am not sure how slow my time series library
> would be without the fortran. It used to be intolerable, but I have the
> impression it may not be too bad now.
For the most part, the numerical methods in S are implemented in Fortran
I think. So even if you don't see it, it's there.
> To some extent this must also apply to the core part of the language. Is there
> not some incentive to remove, not add, both fortran and C except where they are
> essential?
Actually, I quite like Fortran for expressing numerical computations (yes
I should probably keep my dirty habits to myself :-). I'd prefer Algol60
but that's not really an option. I'd certainly like foreign language calls
to remain an option.
Ross
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._