Bertrand Meltz wrote:
> OOF?
>
> [...] As far as I know, there's a lot of OO in the proposed F200x. I
> know that any programming language needs OO, these days, in order to
> be considered. But do we really need it? I don't know much about
> object oriented programming. Just enough to know that we, the users,
> are not ready for it. It does not fit our current programming style.
> And which is more serious, our algorithms are not ready. It might be
> just me, but I have no idea what an object oriented conjugate gradient
> would look like, for example.
You are still thinking procedurally! :-)
I believe that the OO issue in a program is, in general, orthogonal to
its algorithm issues. It deals with various relationships between
modules. For many Fortran "users", they don't have to know much about
OO, since the life is much simpler if the only data class they have to
deal with is the _REAL_array_.
For example, a _conjugate_gradient_solver_ is a _solver_. A _solver_
has a _matrix_, and is associated with two _vectors_. An OO approach
is interested in the definitions of _solver_, _matrix_, and _vector_
(datatypes?), their life-cycles (modules?), and their relationships
(inheritance/aggregation, etc.?), not the CG or any solver algorithm
itself.
Needless to say, for most users or CG algorithm developers, _matrix_ and
_vectors_ are just flat _REAL_arrays_ of different ranks. However,
defining the _matrix_ and the _vectors_ may be the central issue for
most application softwares, not the CG algorithm itself which is in most
cases, cheap, if not already callable from the system math library.
If one cares to take a look at any application program using a CG
algorithm, count the lines of code (LOC) written to define the _matrix_
and the _vectors_ and their operations, and the LOC for the CG algorithm
in the _solver_, one may find that the latter LOC is just a small
fraction of the total, comparing to the former LOC (e.g. I have 1/50 in
KLOC in my directory). There may be nothing interesting algorithmically
to many people in the rest 98% code, but it is where the most
programming and even computational activities are; it is where the most
applications of the Fortran language are; and it is where an OO approach
is most relevant (IMHO).
As a Fortran "user", I do not know much about OO but only enough to be
frustrated often by the complexity in object relationships (in Fortran
90). However, it seems to me that leaping toward OO (with whatever
available in Fortran 90) is a step passing a potential barrier from one
less stable state to another more stable state around a much lower
potential minimum. There is just no way back with my limited energy
level. The best part is, the whole OO issue in Fortran is so confusing
that I know we must be on a totally uncharted territory and we must be
in something big. What should be considered the "true" OO and what not,
may be irrelevant.
Jing
--
________________________________ _-__-_-_ _-___---
Jing Guo, [log in to unmask], (301)614-6172(o), (301)614-6297(fx)
Data Assimilation Office, Code 910.3, NASA/GSFC, Greenbelt, MD 20771
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|