NAG on Fortran, C++, and Java

beliavsky_at_aol.com
Date: 10/27/03 

Date: 27 Oct 2003 07:38:22 -0800

Here is a discussion from Financial Engineering Today about why NAG
still programs in Fortran. The full article is at
http://www.fenews.com/fen34/where_num_matters/where_num_matters.html .

The Future of Quantitative Computing: Part III

By Jim Finnegan

Editor's Note: Dr. Ian Reid is vice president of business development
at NAG. This article is a continuation of an interview we featured in
our last two issues (July/August, September/October). This is the
third and final installment of our three-part discussion.

Finnegan: In our last interview, you mentioned how many of NAG's
algorithms are written in FORTRAN. Why the continued reliance on
FORTRAN for computational efficiency. Why not something else like
C++?

Reid: As some of your readers may know, FORTRAN stands for "formula
translation" and the language was designed purely for mathematical
computation. When it comes to computational efficiency, in most cases
FORTRAN is still the most efficient language. Of course, FORTRAN, like
many other languages, is evolving to the level where mixed language
programming and interoperability is no longer a big problem. Of
course, NAG is not against C/C++, and in fact NAG offers the largest
commercially available C library with broadly equivalent functionality
to our Fortran Library and C++ interfaces. It's also true to say that
the Finance community drove NAG to develop the C library – most groups
in Finance really don't like the ‘F' word!!

As for C++, we used to get lots of requests to do a "pure" C++
library, but now most requests are for Java.

Finnegan: And do you have any plans for a pure C++ or Java library?

Reid: We already have C++ interfaces available and we are working
closely with a number of our software partners (those who integrate
NAG components into their applications) to work out the best way to
integrate the NAG components into their Java applications, in terms of
maintenance and computational efficiency. So far, our experiments show
that a pure "object-oriented Java" solution is both time consuming and
extremely computationally inefficient, but that wrapped (JNI)
solutions and translated (procedural) solutions are viable. Watch this
space!

Relevant Pages

  • Re: NAG on Fortran, C++, and Java
    ... > Here is a discussion from Financial Engineering Today about why NAG ... > algorithms are written in FORTRAN. ... When it comes to computational efficiency, ... > in Finance really don't like the ‘F' word!! ...
    (comp.lang.fortran)
  • Re: New to Python: Features
    ... For numeric computing, yes. ... There's a reason Fortran use has been steadily declining, ... that does strictly numeric computing is pretty small, ... superb compilers _and_ coders for/in ...
    (comp.lang.python)
  • Re: What do you LISPers think of Haskell?
    ... "Lisp is as fast as Fortran for scientific computing" claims economics ... His published software includes a sparse matrix library written in Lisp ...
    (comp.lang.lisp)
  • Re: Settling on Lisp and Tcl
    ... > and adapted to new Fortran version. ... My impression is that many scientists now get by without ever having to use ... > to use deeply structured entities in programming. ... the only person who beat me in the computing project in our year ...
    (comp.programming)
  • NAG on Fortran for finance quants
    ... Malcolm Cohen of NAG has written an article on the advantages of a ... matrix-oriented language like Fortran 2003 for quantitative finance ... promoting Fortran in QF. ... adding NEW procedures ONLY to the F77 and C libraries. ...
    (comp.lang.fortran)