C++ in Numerical Analysis
U37...@uicvm.uic.edu
I am trying to switch from FORTRAN into C++.
As an engeeer, I am wondering what's advantage of programming in C++.
I would really appreciate if someone give me clear answers for the
followings.
1) I understand C++ as an objected-oriented programming language.
Does this really help prgogramming for numerical analysis?
Does this give clear edge over old horse, FORTRAN ?
If the concept of OOP is better, how will it affect the future
of numerical analysis ?
2) Can anyone give what are the calling conventions FORTRAN subroutines
from C++?
I know there is enough discussion for calling Fortran routines
from C.
3) As an experienced FORTRAN programmar, I am not familar with
either C++ or C.
Although I took a courese, C is not my type of language.
Honestly, pointer problems give me a headache.
Can the person like me - who knows only Fortran - learn C++
without full knowledge of C ?
4) One more thing, which language would be better in number crunching
problems ?
Thanks in advance.
Sung T. Kim
Ethan Bradford
ability: You have implemented an algorithm involving matrices, (which
is already more maintainable because it is more readable). You need
to make it handle upper-diagonal matrices. In C++, you just define
what upper-diagonal matrix addition, multiplication, inversion, etc.,
mean and you are done -- your original algorithm (without being
touched) now handles upper-diagonal matrices. In FORTRAN, you copy
the algorithm, substitute your unreadable 6-letter general-matrix
routines with unreadable 6-letter upper-diagonal matrix routines,
being very careful to get every case.
Next step: you need to change the original algorithm. In C++, you
just edit it and it works for all cases. In FORTRAN, you edit two
files.
All these advantages come from operator overloading -- they aren't
even OOP.
--
-- Ethan (eth...@u.washington.edu)
Ethan Bradford
The book "C++ for Scientists and Engineers" by James T. Smith applies
C++ to numerical analysis (NA). He says a bit about its advantages
over FORTRAN. I haven't read all the book yet, so I can't give a good
opinion as to its quality. It is heavily based in Turbo C++. The
author defines a class for NA, called MSP, which is available from him
on IBM floppies.
--
-- Ethan (eth...@u.washington.edu)
Dag Bruck
>Dear Netters:
>
> Although I took a courese, C is not my type of language.
> Honestly, pointer problems give me a headache.
One of the advantages of C++ is that you can hide the details of the
implementation from the users of a package. You can write a NA
library in such a way that the user does not have to worry about
pointers.
I suggest that you take a look at
Andrew Koenig: "C Traps and Pitfalls," Addison-Wesley
which has a discussion of pointers vs. arrays. Because of the strong
heritage from C, most of "C Traps and Pitfalls" also applies to C++.
The main difference between C and C++ is that C++ gives the careful
programmer some mechanisms to hide the traps and pitfalls.
Walter Bright
/As an engeeer, I am wondering what's advantage of programming in C++.
/1) I understand C++ as an objected-oriented programming language.
/ Does this really help prgogramming for numerical analysis?
/ Does this give clear edge over old horse, FORTRAN ?
/ If the concept of OOP is better, how will it affect the future
/ of numerical analysis ?
There are many netters more eloquent about the advantages of OOP over
C++ than me. I'll talk about numerical programming in particular.
C, as standardized by ANSI C, and C++ by the ARM, have some serious
shortcomings for the numerical programmer:
1. Most of the floating point stuff is left "implementation defined".
2. No requirement for IEEE 754 arithmetic.
3. No support for NaNs or infinities.
4. No support for the floating point environment, that is, rounding
modes, precision control, and exception handling.
5. C's weak support for variably dimensioned arrays.
6. Optimization of array operations is inhibited by the 'aliasing'
problems.
7. No complex numbers in C.
8. A lot of the standard functions available in the FORTRAN library
are not standard in C.
9. On the IBM PC, you have to resort to all kinds of kludges to
have arrays bigger than 64K bytes, a common occurrence in FORTRAN.
The only reason I can come up with why these problems exist is that
C compiler implementors and their managers aren't numerical programmers.
They don't support numerical programmers because they don't see a demand
for it, and numerical analysts don't use C because of the poor support.
A vicious circle.
The NCEG (Numerical C Extensions Group) has set out to change all that.
They've come up with an interesting document NCEG 91-015 that addresses
problems 1,2,3,4 and 8. They have some other less well developed documents
that address the other problems.
Problems 5,6 and 7 can be solved with C++. 7 is easy, every C++ implementation
has a complex class for it. C++ is ideal for defining new types like that.
The NCEG group is trying to extend the language to add complex to C, but this
seems to me to be a waste of time, as I cannot see any significant advantage
to their proposal over the C++ class. Problems 5 and 6 are addressed by
an appropriate array class library for C++. Two examples are M++ by Dyad
Software and Rogue Wave's class library.
One puzzling aspect of NCEG's work is the nearly total lack of any mention
of C++. This doesn't affect NCEG 91-015, which smoothly integrates into
C++ as well as C. I know this because I implemented NCEG 91-015 for
Zortech's C and C++ compilers.
Problem 9 is at last solved with the advent of inexpensive 32 bit compilers
and associated DOS extenders.
/2) Can anyone give what are the calling conventions FORTRAN subroutines
/ from C++?
In C++, you bracket the FORTRAN subroutines with:
extern "FORTRAN" {
...
}
which causes the C++ compiler to use the FORTRAN calling conventions
for the functions declared between the {}. Of course, you must be
using a C++ compiler that supports extern "FORTRAN" (this is not
required by the ARM).
/3) As an experienced FORTRAN programmar, I am not familar with
/ either C++ or C.
/ Can the person like me - who knows only Fortran - learn C++
/ without full knowledge of C ?
I've done a lot of programming in FORTRAN. I used to write engineering
analysis tools for Boeing. I tried to use FORTRAN on the IBM PC back
in '82. The compilers available then were unusable. I got a hold of
a C compiler, learned C, and never wrote a FORTRAN program again.
You'll have to make your own decision, of course.
/4) One more thing, which language would be better in number crunching
/ problems ?
This is strongly dependent on which compiler you choose. An excellent
FORTRAN compiler is better than a crummy C++ compiler, and vice versa.
With IEEE 754, NCEG 91-015, and a good class library, there is
nothing that FORTRAN has inherently over C++ anymore.
Ian Angus <iangus>
>
>I am trying to switch from FORTRAN into C++.
>As an engeeer, I am wondering what's advantage of programming in C++.
>I would really appreciate if someone give me clear answers for the
>followings.
>
My answers are based upon a paper I (Ian Angus) and Tilt Thompkins
published in the proceedings of the 4th Conf. on Hypercubes,
Concurrent Computers and Applications which was held in Monterey,
California in March 1989.
Very briefly, the paper discussed the results of the conversion of a
Fortran Computational Fluid Dynamics code (based upon Tony Jameson's
Flo57) to C++.
Our intent was to see if writing such a code in C++ would enable us
to write applications in such a way that they would be portable from
sequential machines TO distributed memory computers.
(Porting a code from a distributed memory to a sequential machine is
essentially trivial)
The idea was to encapsulate the data level parallelism inside class
objects.
The results were very encouraging, and showed that the desired for
portability could be achieved.
Unfortunately, there was a cost of some runtime efficiency.
On the average, the C++ code ran about a factor of 2 slower than the
C or Fortran version. These results were very machine/compiler
dependent; the best result was 1.5, the worst about a factor of 3.
The C++ code was also something of a memory hog.
It needs to be pointed out that the Fortran and C++ codes were not
just syntactically different.
The programs ended up having a fundamentally different structure
which is enforced by extensive use of C++'s data abstraction to
emulate the mathematical abstractions of continuum field theory
and its discretization.
A notable feature of the C++ code was that the array indexing
was hidden. This at the very least meant that one of the most common
sources of bugs in Fortran numerical codes had been eliminated.
The C++ code also turned out to be easier to modify to incorporate
alternative interpolation schemes, etc.
In short, it is easier to see what the C++ code is trying to do
vis a vis its Fortran cousin.
We didn't solve every problem in our paper. There are many severe
difficulties pertaining to boundary conditions that we are slowly
overcoming. Some of these results will be published very soon.
With these introductory comments I will take stab at some of the
questions.
>1) I understand C++ as an objected-oriented programming language.
> Does this really help prgogramming for numerical analysis?
It does if you are using, or plan to use, a distributed memory machine.
> Does this give clear edge over old horse, FORTRAN ?
Until the efficiency issues are resolved, I suspect that Fortran will
have the edge.
C++ is most likely to make inroads into Fortran usage for some new
codes, and in cases where the applications are very complicated,
and constrained to execute on a massively parallel machine, that
the agonies of writing the application in Fortran will scare the
programmers into using something other than Fortran
> If the concept of OOP is better, how will it affect the future
> of numerical analysis ?
I would say "Wait and see". I don't know.
>
>2) Can anyone give what are the calling conventions FORTRAN subroutines
> from C++?
> I know there is enough discussion for calling Fortran routines
> from C.
>
I would presume that most of the discussion for C applies to C++.
I don't know of a compiler that supports the `extern "Fortran"'.
Presuming that in your environment calling Fortran from C is a solved
problem, provide C bindings for your Fortran routines and then call
them from C++ using `extern "C" ...'.
>3) As an experienced FORTRAN programmar, I am not familar with
> either C++ or C.
> Although I took a courese, C is not my type of language.
> Honestly, pointer problems give me a headache.
> Can the person like me - who knows only Fortran - learn C++
> without full knowledge of C ?
>
Yes.
>4) One more thing, which language would be better in number crunching
> problems ?
>
If the runtime efficiency problems get resolved so that a C++ code
is only, say 10%, slower than its Fortran equivalent, and the
application is large, then I believe that using C++ will be a big
win. For parallel processing C++ may be better even with the
performance problems.
If you application is simple, and doesn't have to run on all
kinds of parallel computers, then I doubt what you use will matter.
>Thanks in advance.
>
>Sung T. Kim
Another paper to look at that discusses subject of C++ and numerical
computing was published in the 2nd Usenix C++ Conf. proceedings
by David Forslund et. al.
If you can't trace a copy of our Fluid Dynamics paper, or have other
questions, contact me at (213) 544-5210 or ian...@nrtc.northrop.com.
/ian (Ian Angus)
Steve Warwick
replacement for FORTRAN, how come it doesnt have a power operator??
you know, "^" or something.....
( A while ago, this question was raised, and drifted into a discussion
of user-defined operators, but that's another story. )
I've heard about this numerical C group for years. Is it really true,
as Walter insinuates, that the numerical extentions can be added as
classes into C++ in an efficient enough manner that they need not be
implemented in the compiler itself??
I have to admit, I'm skeptical. If its not as efficient, does it make
sense to propose that numerical C extentions be added to the C++
definition?
Jim ADCOCK
|6. Optimization of array operations is inhibited by the 'aliasing'
| problems.
|an appropriate array class library for C++. Two examples are M++ by Dyad
|Software and Rogue Wave's class library.
I'm curious what they did that you consider "solving the alias problem" ???
Matt Austern
> Not to raise the dead or anything, but if C++ is such a great
> replacement for FORTRAN, how come it doesnt have a power operator??
>
> you know, "^" or something.....
This has bothered me for a while too. Yes, maybe it's just a
syntactic nicety (or, as Numerical Recipes suggests, maybe it's an
obstacle to generating more efficient code), but it is an annoyance.
It's yet another reason to keep numerical programmers from switching
from FORTRAN to C or C++.
In C, I just defined SQUARE and CUBE macros, or called pow, but I keep
thinking that in C++ there must be a better way.
You could, I suppose, define a RealNumber class or something like
that, and then overload an operator to serve as exponentiation. The
problem is that there isn't any appropriate operator with a high
enough precedence. Overloading ^ for exponentiation, for example, is
just asking for trouble.
Has anybody out there found a decent way of handling this?
--
Matt Austern ma...@physics.berkeley.edu Lots of things worth saying
(415) 644-2618 aus...@lbl.bitnet can only be said loosely.
Walter Bright
/In article <3...@nazgul.UUCP> bri...@nazgul.UUCP (Walter Bright) writes:
/|6. Optimization of array operations is inhibited by the 'aliasing'
/| problems.
/|to their proposal over the C++ class. Problems 5 and 6 are addressed by
/|an appropriate array class library for C++. Two examples are M++ by Dyad
/|Software and Rogue Wave's class library.
/I'm curious what they did that you consider "solving the alias problem" ???
I'm more familiar with M++ than Rogue Wave. What M++ does is use C++'s
facilities to provide a complete array language extension to C++.
Then, instead of doing your array operations with loops, you use the
overloaded operators and functions for the array language. The implementation
of those operations is in hand-coded custom library routines.
So, if you wanted to do an element by element add of arrays A and B to get
C, in M++ it becomes:
C = A + B;
Of course, if you still write your array operations as loops over each
element, the aliasing problem persists.