From chemistry-request@ccl.net Sat Dec  7 00:40:18 1991
From: wetmore@theochem.waterloo.edu (Ross W. Wetmore)
Subject: Re: Fortran vs. C: quick thought
To: chemistry@ccl.net
Date: Sat, 7 Dec 91 0:25:40 EST
Status: R

> [...]  Why must we, as developers and programmers, (1) take our
> equations which are often formulated in terms of matrix and vector
> operations, (2) convert them to loop-based code (an error-prone
> process that usually requires much more debugging than coding), and
> (3) cross our fingers and hope that the compiler "recognizes" it and
> turns it back into the original matrix expression?  We shouldn't, and
> with Fortran 90, we finally, after 15 years, have a language that
> allows us to turn our equations directly into code.  In this respect,
> the only remaining question is how well the vendors are going to
> support this capability.
> 
> What does this have to do with Fortran and C?  Fortran 90 puts C TWO
> generations behind instead of just one.  If it took us 15 years to
> finally get array syntax standardized in Fortran, how much longer
> would it take us to get it, along with variable-dimensioned arrays and
> user-defined subscript ranges, into C?  
> -ron shepard
> shepard@tcg.anl.gov

  I don't want to add fuel to such an explosive topic, but just a quickie
thought on a thread that seems to run through the above.

  The thread is the lament at the time it seems to take to see improvements
in some areas of compiler technology. It should be noted that numerical
computation is relatively straightforward and not one of the cutting edges
of compiler research. Commercial development can provide some added value
and thus advantage in selling new hardware, but the scientific/computational
niche is not the largest nor most lucrative segment of the market. On the
other side, there are a growing number of computational scientists, and a
growing awareness of the need to both learn more about and interact more
with some of the source disciplines that provide this technology to them,
but there is still a lot of reluctance to get really involved.

  To the computer scientist, FORTRAN is an incredibly ad hoc language that
is incredibly difficult to parse, has very poor structural basis and
consequently lends itself very poorly to a lot of the structural analyses
and safety net features that are taken as fundamental truths. It is not
likely that there will be much common ground found with them in discussions
of how to extend FORTRAN, especially when issues of backwards compatibility 
are raised.

  There has been some mention of C++ by a few posters, and while I don't
want to suggest anything particular about this name (it could be F++ for
all I really care), there are a couple useful advances in compiler technology
that it brings out. The first is an easy (for the skeptical, would you accept
easier) way to provide reusability of code through its concepts of Classes
and sub-Classes and the methods or operations that each Class is capable of
performing. It is very much possible to provide libraries of understandable
syntax tailored functions and novel data types that are built on layers of
previous, but simpler or more elementary components. The second is the
degree to which these additions interact and become a part of the compiler
technology itself - in essence the developer of a Class library is able
to redesign the language for those who would make use of such extensions.

  Converting old codes is largely a waste of time if they run fine and do
the job that they were designed to do. But computational scientists that
are developing new applications, or new methods might be best served if
they took a quick look at some of the new toys that computer scientists 
are busy experimenting with and tried to enlist some cooperation in seeing
just how they might be applied. It is just possible that encapsulating a
lot of old code and algorithms with a thin wrapper of some of the latest
and greatest technology could result in a best of both worlds scenario where
new development could take off from a structurally sound and aesthetically
pleasing (to some) base, while retaining much of the computational efficiency
and known quality of the existing numerical software. One of the beauties 
of some of the new ways is that well designed interfaces hide and isolate a 
lot of the nitty gritty and thus make possible the replacement of large 
amounts of underlying structure without anyone being the wiser. A gradual
replacement and enhancement policy is a viable approach in such an environment.
Moreover, it is an approach that does not impede real use of the system
during the process.

  I guess this got a little longer than expected, but rather than stirring
up old fires of whose native language is better, if both start learning a
little computer esperanto for public discourse, and reserve their native 
tongue for use at home, there are a lot of interesting possibilities.

Ross W. Wetmore                 | wetmore@theochem.waterloo.edu
Waterloo, Ontario               | {backbone}!watmath!rwwetmor


From chemistry-request@ccl.net Sat Dec  7 17:20:04 1991
Date: Sat, 7 Dec 91 11:26:37 PST
From: d3f012@gator.pnl.gov
Subject: Fortran vs. C
To: chemistry@ccl.net
Status: R



  Debating Fortran vs. C merely clouds the larger issue.  We should be more
 concerned with procedural vs. object-oriented.  Object oriented design (OOD)
 has the potential to deliver more robust codes that are easier to develop,
 maintain, and interact with other codes.  Granted, the numerically intensive
 kernals could be written in what ever language gives the best performance.

 The increasing importance in distributed computing as well as the
 release of a specification of an Object Request Broker (ORB) by the
 Object Management Group (OMG) underscores the potential importance of 
 Objects in the computational sciences. (The OMG is a consortium of industry
 and government agencies aimed at developing standards for the growing
 OO industry.  The ORB is an attempt to standardize the way that objects
 can invoke the methods of other objects across multiple platforms)

 Rewriting thousands of lines of old dusty-deck Fortran codes does seem
 daunting.  The first step in modernizing these old programs could be 
 to encapsulate them, and gradually move portions of them into a more
 fine grained OO framework.  This itself could be a complex issue and 
 should be discussed.  One should attempt to leverage past codes if possible.  
 One problem with encapsulating these old Fortran codes is that they 
 sometimes have liberal (and often uncontrolled) use of Common Blocks 
 which renders them highly un-modular, and hence difficult to
 encapsulate.

 A few years ago, I wanted to perform some semi-empirical calculations
 on the bacterial photosynthetic reaction center.  The existing software
 available to me at the time was an engineering nightmare and totally 
 inadequate (it still is).  This was a case of realizing that it was 
 better to throw out the old and simply redesign an entirely new program. 
 (caveat:  I realize that a total redesign would be much more difficult 
 for large ab initio programs and I am not necessarily advocating that)
 To make this research possible, I designed a new electronic structure 
 code (to be written in C++).  The code, named Argus, was finally 
 implemented in C due to the lack of native C++ compilers on Cray's.  
 However, the basic underlying components of OOD have been retained; 
 encapsulation, abstraction, polymorphism, albeit in a procedural 
 implementation.  Argus has been a great success for this research 
 and all our photosynthetic work has been done with this program.  The 
 take-home lesson is that in terms of overall efficiency: human time for 
 design, bugfixing, maintaining, adding new features, as well as compute 
 performance through a judicious use of Scilib calls on the Cray, and 
 careful coding to avoid "wild" pointers, etc, Argus greatly outperforms 
 the older code.  I believe that this composite performance differential 
 would be enhanced by a further refinement of Argus to an OO language, 
 in this case C++.  Therefore, Argus is currently being restructured 
 as a true OO program. 

 I have recently implemented (in C) some prototype MD kernals
 as well as a functional MD program on the Intel Delta (512 processor
 i860 2D-mesh).  We have seen no tangible performance hit in using
 C relative to Fortran on this machine.

 C++ is not a perfect OO language, this is a developing area and
 the possibility of OO features in Fortran in an interesting thought.
 I've recently heard that OO Cobol is in the works! though I would not
 recommend it for computational chemistry.

 
 I propose that we open discussion on the topic of "Objects in Quantum
 Chemistry" (apologies if this discussion has occured already).  I would
 be interested in seeing movement towards libraries of computational
 chemistry objects that could be used by many different applications. The
 basics of this discussion does not have to center on any particular 
 language.  If this is not the forum for a discussion of this sort, then
 at least, I would like to encourage awarness of this issue.




   Mark A. Thompson
   Molecular Science Research Center
   Battelle Pacific Northwest Laboratory
   Richland, Wa.
 
   d3f012@pnlg.pnl.gov