Is Fortran dead?
Dr. H. R. Myler
in the process of researching a paper that I am writing for the ASEE
Southeast Conference on my approach to teaching engineering programmming
using both C and Fortran. I have written a text book titled "Fundamentals
of Engineering Programming with C & Fortran" that has been published by
Cambridge University Press. If interested you may browse:
http://www.cup.org/Titles/62/0521620635.html
I have always felt that an engineer's education was incomplete if they did
not know Fortran; however, the same may now be said of C. I know of no
engineering curriculum that can afford the luxury of a two semester basic
programming course (for all engineers) that would cover two languages. As
a result, I decided to start teaching both C and Fortran simultaneously,
where I use the slogan "Read Fortran, write C". The students learn to
program in C, but additionally I show what the same Fortran routine would
be and I require them to translate Fortran into C as well as learn the
fundamental contructs of Fortran.
The perennial issue that arises has always been "Why bother with Fortran at
all?". I would value your comments on this subject.
Thank you,
Pls respond to: h...@engr.ucf.edu
--
Prof. Harley R. Myler Whoever is a teacher
Dept. of Electrical & Computer Engr. through and through takes all
University of Central Florida things seriously only in relation
Orlando, Florida 32816-2450 to his students--even himself.
407.823.5098(ofc)/823.5835(fax) --Friedrich Nietzsche
http://macmyler.engr.ucf.edu (Beyond Good and Evil, 63).
Roy Buzdor
>
> I don't know! I am in the process of researching
> The perennial issue that arises has always been "Why
> bother with Fortran at all?".
I have been working in industry (everything from medical
to automotive manufacturing) for 25 years. I saw Pascal
come (and go, for the most part), along with the current
language du jour. All the while, I have seen and
maintained code in Fortran. If the only language that
your students knew was Fortran, they could still be
gainfully employed for the next 30 years maintaining
current applications.
The beauty of fortran, from an engineering point of
view, is that the mathematical structures of the language
is closer to engineering formulae than most any other
programming language.
--
Buz (8
+--------------------------------------------------------------+
| My opinions are seasoned with wisdom, gathered long and hard |
| from experience. They are of great value, and I do not toss |
| them aimlessly to anyone. I carefully share them with those |
| whom I trust will treasure the gift that I bestow upon them. |
+---------------------------------------+----------------------+
| This is official written notice: | My real address is: |
| Please remove me from your mailing | lnuslad dot dzvg41 |
| list. | at eds dot com |
+---------------------------------------+----------------------+
Bukic
> As a result, I decided to start teaching both C and Fortran simultaneously,
What version of Fortran are you teaching? If you are teaching Fortran
90 or 95, or a subset such as Elf90 or F, the answer to "why learn Fortran"
should be self-evident, especially if you assign problems where manipulations
of vectors and arrays are necessary. I think array operations and array
sections are the coolest feature of Fortran 90/95.
Besides, who needs darn semicolons on each line? :)
Vivek Rao
Dan Tex1
>The perennial issue that arises has always been "Why bother with Fortran at
>
>Thank you,
>
>Pls respond to: h...@engr.ucf.edu
>
>--
>Prof. Harley R. Myler
I find that an interesting question. I am an engineer myself. There are
several hundred engineers in the organization I work for. I find that very
few of them are very good at programming ( in any language ). I think that
part of the reason for this is that most engineers are not programmers. They
haven't spent the time ( nor will they ) learning good programming skills and
techniques.
In light of that understanding ( on my part at least )... maybe the perinneal
issue should be... "Why bother with C at all?"
I don't personally have any dislike for C or C++. I don't even actually know
C. I gave my self a several week crash course in C++ a while back to
determine if it might meet my needs better than Fortran. What I found was...
Fortran was much easier to use for mathematical manipulations ( my main use for
it ). The syntax of Fortran was IMHO much, much simpler and more straight
forward than C. Additionally, manipulating character data in Fortran is so
easy a bunny rabbit could do it. Admitedly, I didn't spend enough time with
C++ to learn if there were easier and more straight forward ways a manipulating
data, both numerical and string. I did however acquire several modern books
on C and C++ and found that I could spend hours sifting through them trying to
find out how to do some simple operations. For example.. how to raise a
number to some power? I haven't seen that in a single C++ book yet.
So... for engineers who will take only one programming class ( the one I took
in school consisted of a couple weeks out of a Quarter ), I ask... why learn
C. I personally think that C takes longer to learn than Fortran simply
because of its syntax. Additionally, most of the short mathematical
programs your average engineer will write aren't really worth the time
investment it takes to learn C good enough to write their programs. At least
not when the same program might be written in Fortran in a much shorter time
frame.
Dan :-)
PS. These are my opinions and nothing else.
As such.. Everyone is entitled to them. :-)
LC's No-Spam Newsreading account
> >
> > I don't know! I am in the process of researching
I suppose because Fortran is legible, and C isn't ? :-)
But what about the poor guys who then have to read the C you wrote ? :-)
> > The perennial issue that arises has always been "Why
> > bother with Fortran at all?".
Why not ?
It is a language with a fast learning curve for scientists, it's not
overloaded with features they do not need, they know it and can teach it
to their students. C after all is a glorified assembler.
Somebody else added :
> The beauty of fortran, from an engineering point of
> view, is that the mathematical structures of the language
> is closer to engineering formulae than most any other
> programming language.
I must say, that, once in a lifetime, scientists and engineers may agree :-)
Replace "engineering" with "science" and "scientist" in the sentence above
and I'll endorse it. I've seen only IDL to have a (partially) even better
notation (but IDL costs money) : actually IDL IF, FOR etc. statements are
clumsier than Fortran, only the vector notation is neater, but that went into
f90, didn't it ?
Anyhow, "the determined real programmer can write Fortran programs in any
language" ... :-)
#define NE !=
#define EQ ==
#define LE <=
#define LT <
#define GE >=
#define GT >
#define NOT !
#define AND &&
#define OR ||
#define ENDIF };
#define ENDWHILE };
#define ENDDO };
----------------------------------------------------------------------
nos...@ifctr.mi.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.
i...@svpal.org
Roy Buzdor <res...@home.comfortably> wrote:
> Dr. H. R. Myler wrote:
> >
> > I don't know! I am in the process of researching
> > ... I use the slogan "Read Fortran, write C".
> > bother with Fortran at all?".
>
> to automotive manufacturing) for 25 years. I saw Pascal
> come (and go, for the most part), along with the current
> language du jour. All the while, I have seen and
> maintained code in Fortran. If the only language that
> your students knew was Fortran, they could still be
> gainfully employed for the next 30 years maintaining
> current applications.
>
> view, is that the mathematical structures of the language
> is closer to engineering formulae than most any other
> programming language.
One might also note that there does not seem to be a FORTRAN
equivalent to the "Obfuscated C Competition".
This is not to say you cannot write FORTRAN code that looks like
a dog's breakfast, simply that it isn't as easy as in C and C++.
IMHO, C enables obfuscation, C++ invites it.
IBM
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Robert Orban
nos...@ifctr.mi.cnr.it says...
>
>Dr. H. R. Myler wrote:
>> >
>> > I don't know! I am in the process of researching
>> > ... I use the slogan "Read Fortran, write C".
>
>But what about the poor guys who then have to read the C you wrote ? :-)
>
>> > bother with Fortran at all?".
>
>It is a language with a fast learning curve for scientists, it's not
>overloaded with features they do not need, they know it and can teach it
>to their students. C after all is a glorified assembler.
>
>Somebody else added :
>
>> view, is that the mathematical structures of the language
>> is closer to engineering formulae than most any other
>> programming language.
[snip]
It seems to me that Fortran's current huge weakness is total lack of support
for portable visualization. EVERY very-high-level language designed for
engineers and scientists (MathCad, Matlab, Gauss, Macsyma, Maple, Mathematica,
etc. etc.) has support for easy visualization of results. Fortran has ZIP.
There are a lot of third-parties out there who will sell you a package to add
on to your Fortran compiler to do visualizations, but every one is
incompatible with the next. So the big selling point of Fortran
(cross-platform standardization) becomes moot the moment you add a third-party
visualization package.
It seems to me that even a fairly elementary set of visualization
instructions, added to the standard, would greatly improve Fortran's chances
to survive in the 21st century in more than a few supercomputer centers
where its support for parallel processing is useful. In my field (electrical
engineering/signal processing) Fortran is basically extinct and I cannot
remember a refereed journal article in this field in the last 10 years using
Fortan code. It's all Matlab and C now.
Dan Tex1
>It seems to me that Fortran's current huge weakness is total lack of support
>for portable visualization. EVERY very-high-level language designed for
>engineers and scientists (MathCad, Matlab, Gauss, Macsyma, Maple,
>Mathematica,
>etc. etc.) has support for easy visualization of results. Fortran has ZIP.
That's an interesting statement. The problem with it however is that most
languages don't have standard graphics capabilities either. C and C++
certainly don't have graphics. Any graphics you get with one of those
compilers is a vendor add on. That doesn't sound too portable to me?
>In my field (electrical
>engineering/signal processing) Fortran is basically extinct and I cannot
>remember a refereed journal article in this field in the last 10 years using
>Fortan code. It's all Matlab and C now.
>
I don't know about "signal processing" per se, but I do have some EE friends
and Fortran appears to be alive and kicking in many places where electricals
work.
As for Matlab (and similar programs), I've never used it myself. I have
heard about it and it seems quite popular. However, it seems that speed is
definitely not something one tends to get with such a product. Additionally..
is it portable ( I don't know myself ). Based on what I've heard on here and
elsewhere, I tend to equate Matlab with programs like Microsoft Excel...
quite useful, but it has it's limits ( though I'll bet money it has less
bugs than Excel :-) ).
Feel free to correct me on any of the above. I realize I'm overstepping my
knowledge on some of these products a bit.
Dan :-)
Michael Metcalf
engineering/signal processing) Fortran is basically extinct and I
cannot
remember a refereed journal article in this field in the last 10
years using
Fortan code. It's all Matlab and C now.
a large European company responsible for electrical power
distribution to an entire country. Fortran is their
sole language.
Mike Metcalf
--
Stefan A. Deutscher
>In article <Pine.OSF.3.95.98092...@poseidon.ifctr.mi.cnr.it>,
>nos...@ifctr.mi.cnr.it says...
>
>support for portable visualization. EVERY very-high-level language
>designed for engineers and scientists (MathCad, Matlab, Gauss, Macsyma,
>Maple, Mathematica, etc. etc.) has support for easy visualization of
>results. Fortran has ZIP.
EVERY is a very bold overstatement, and very-high-level language is not
a very clear definition for me. Neither Ada nor Pascal nor Modula have
visualization stuff. Nor does C, for that matter, even though it may be
a matter of taste and religion to call it a very-high-level language
or even just a high-level language.
>There are a lot of third-parties out there who will sell you a package
>to add on to your Fortran compiler to do visualizations, but every one
>is incompatible with the next. So the big selling point of Fortran
>(cross-platform standardization) becomes moot the moment you add a
>third-party visualization package.
As does using Mathematica. My pet-OS is OS/2, Mathematica for that is
seemingly frozen at version 2.2x, and the frontend is more or less text
based. I heared that Maple has dropped OS/2 support as well or will do
so. Many of the products you mentioned run on fewer platforms than
fortran. However, nothing keeps you from creating your data with Fortran
codes on the fastest hardware around (which may not even have graphics
hardware, like the NEC vector supercomputer I use) and then visualize it
with what ever tool you see fit, on which ever platform it requires.
>It seems to me that even a fairly elementary set of visualization
>instructions, added to the standard, would greatly improve Fortran's
Like what? Draw a line? A pixel? What if your output device can't do
pixels or lines? This would enter a world of hardware dependent driver
issues, just check out the gnuplot distribution to see how they handle
the various terminals.
The only common denominator seems to be to print stuff to a terminal (or
printer of file), along the lines of gnuplot's dumb terminal:
G N U P L O T
version 3.5 (pre 3.6) patchlevel beta 340
last modified Tue Nov 25 22:57:44 GMT 1997
gnuplot> set term dumb feed 60 12
gnuplot> plot sin(x)
1 ++----------***-----------+-***-------+------**---++
0.8 ++ *+ * + * * sin(x) ******++
0.6 *+ * * * * * * ++
0.4 +* * * * * * **++
0.0 +* * * * * * *++
-0.2 ++* * * * * * *+
-0.4 ++** * * * * * *+
-0.6 ++ * * * * * * +*
-0.8 ++ * * + * * + * +* ++
-1 ++---**------+-------***--+----------***----------++
-10 -5 0 5 10
but that you can really do already with gnuplot or with a few small
subroutines which IMHO don't belong in a language spec.
>chances to survive in the 21st century in more than a few
>supercomputer centers where its support for parallel processing is
>useful. In my field (electrical engineering/signal processing) Fortran
>is basically extinct and I cannot remember a refereed journal article
>in this field in the last 10 years using Fortan code. It's all Matlab
>and C now.
Uff. I don't know your background but that statement surprises me. To
some extent it is also at variance with what others here say and do for
a living.
Finally, that you "... cannot remember a refereed journal article in
this field in the last 10 years using Fortan code..." only says that
either you simply cannot remember, or that you read a very selective
group or even a small number of papers, or that simply nobody bothers to
tell you what language they used unless they used Matlab or C.
Certainly, for some hardware control applications C seems more
appropriate, while for some energy flow modeling or other number
crunching Fortran may be the better tool
I can't remember many of the 1100+ articles in my private collection of
papers on atomic physics stating explicitly that they use computer codes
written in Fortran --- or in any other language for that matter.
While the people you talk to turn out to use Fortran more often than
not, details like 'We used the IBM xlf 5.0 compiler with the following
fixpacks and the compiler options listed in table 2 to compute the
data.' are totally out of place unless you benchmark things. Nobody will
brag about such details. Nobody cares, just as nobody cares what kind of
pencil I use to draft my papers.
The papers are on physics. This is what I want to know, this is what I
expect to read.
So, I think visualization has little to do with the ability of Fortran
to survive. (Command line / parameter handling, on the other hand ...
:->)
Cheers, Stefan
--
=========================================================================
Stefan A. Deutscher | (+33-(0)1) voice fax
Laboratoire des Collisions Atomiques et | LCAM : 6915-7699 6915-7671
Mol\'{e}culaires (LCAM), B\^{a}timent 351 | home : 5624-0992 5624-0992
Universit\'{e} de Paris-Sud | email: s...@utk.edu
91405 Orsay Cedex, France (Europe) | (forwarded to France)
=========================================================================
Do you know what they call a quarter-pounder with cheese in Paris?
Dan Pop
> One might also note that there does not seem to be a FORTRAN
> equivalent to the "Obfuscated C Competition".
That's only because it's too easy to do it in fixed form FORTRAN.
Not having whitespace as a token separator is a mine of gold for the
FORTRAN obfuscator. I guess everybody in this newsgroup has heard of the
famous DO 5 I=1.5 bug, which is a brilliant example of (involuntary)
FORTRAN obfuscation.
Many years ago someone posted an excellent example of obfuscated FORTRAN,
which made extensive use of that (mis)feature combined with lines
continued in very misleading ways. Unfortunately, I didn't keep a copy,
but maybe someone else did.
Then, if you try to write a piece of nontrivial code using *only* the
FORTRAN II features, the code will come out naturally obfuscated :-)
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - EP, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Martin Ambuhl
> Nor does C, for that matter, even though it may be
> a matter of taste and religion to call it a very-high-level language
> or even just a high-level language.
For a poster to clf to take this swipe at C requires a good deal of
religion or else gross ignorance. Since you seem knowledgeable enough,
I hope you put a big donation in the plate at Our Mother of the Holy
Fortran.
--
Martin Ambuhl (mam...@earthlink.net)
Note: mam...@tiac.net will soon be inactive
Juergen v. Hagen
> for portable visualization. EVERY very-high-level language designed for
> engineers and scientists (MathCad, Matlab, Gauss, Macsyma, Maple, Mathematica,
> etc. etc.) has support for easy visualization of results. Fortran has ZIP.
I don't think that vizualization belongs into a number-crunching code. I
think
the number-crunching code should be highly portable, running on any
machine.
From the GUI machine (basically any machine, even a cheap 486 could be
sufficient) run then the job on the Cray. The protable number-crunching
code
seems to be Fortran with the perspective of F2K or HPF. The viz part
can go into a wrapper written in any language (I favour tcl/tk for
simple
window environments as the script can then be run on Winod$e AND
X-Windows
which makes the stuff even more portable). Again, you should use the
language
suited for the job for the job at hand. For viz use tcl/tk or then (also
portable) OpenGL.
Using Mathematica or Matlab for numbercrunching can sometimes not be a
possibility. If you need hours on a Cray, what will you spend on Matlab?
juergen
Gary Strand
ro> It seems to me that even a fairly elementary set of visualization in-
structions, added to the standard, would greatly improve Fortran's chances
where its support for parallel processing is useful.
Why would I want to waste valuable CPU seconds visualizing intermediate results
on the same platform as I'm doing my number-crunching?
Let Fortran generate the data and dump it out; I'll use my cheap workstation
to make pretty pictures ins
--
Gary Strand
stra...@ucar.edu http://www.cgd.ucar.edu/ccr/gary
Robert Orban
says...
>
>
>ro> It seems to me that even a fairly elementary set of visualization in-
> structions, added to the standard, would greatly improve Fortran's
chances
> to survive in the 21st century in more than a few supercomputer centers
> where its support for parallel processing is useful.
>
>Why would I want to waste valuable CPU seconds visualizing intermediate
results
>on the same platform as I'm doing my number-crunching?
>
>Let Fortran generate the data and dump it out; I'll use my cheap workstation
>to make pretty pictures ins
If you are using this sort of distributed system you wouldn't have to use any
of the proposed visualization commands in the code running on the
supercomputer. But many folks now run Fortan code on workstation-class
computers or PCs, where the same CPU would do the number crunching and the
visualization computations.
Robert Orban
says...
>
>
>>It seems to me that Fortran's current huge weakness is total lack of support
>>for portable visualization. EVERY very-high-level language designed for
>>engineers and scientists (MathCad, Matlab, Gauss, Macsyma, Maple,
>>Mathematica,
>>etc. etc.) has support for easy visualization of results. Fortran has ZIP.
>
>languages don't have standard graphics capabilities either. C and C++
>certainly don't have graphics. Any graphics you get with one of those
>compilers is a vendor add on. That doesn't sound too portable to me?
>
>>engineering/signal processing) Fortran is basically extinct and I cannot
>>remember a refereed journal article in this field in the last 10 years using
>>Fortan code. It's all Matlab and C now.
>>
>
>and Fortran appears to be alive and kicking in many places where electricals
>work.
>
>As for Matlab (and similar programs), I've never used it myself. I have
>heard about it and it seems quite popular. However, it seems that speed is
>definitely not something one tends to get with such a product.
Additionally..
>is it portable ( I don't know myself ). Based on what I've heard on here
and
>elsewhere, I tend to equate Matlab with programs like Microsoft Excel...
>quite useful, but it has it's limits ( though I'll bet money it has less
>bugs than Excel :-) ).
Matlab now has a compiler that turns the M-code (interpreted) into C, which
can be compiled and optimized in the usual way.
I see more and more papers published using Matlab code because, among other
things, it comes with a series of toolboxes written by very competent people,
so researchers can spend less time reinventing the wheel and more time working
on their research.
Admittedly one of Fortran's great strengths is the wide variety of
well-established subroutines available from sources like NETLIB. But these are
still more time-consuming to incorporate than the Matlab equivalents.
Robert Orban
11354...@CompuServe.COM says...
>
>In my field (electrical
>engineering/signal processing) Fortran is basically extinct and I
>cannot
>remember a refereed journal article in this field in the last 10
>years using
>Fortan code. It's all Matlab and C now.
>
> a large European company responsible for electrical power
> distribution to an entire country. Fortran is their
> sole language.
>
>
> Mike Metcalf
Signal processing and electrical power distribution are very partitioned from
each other in the EE community. They're two distinct specialties and, other
than the basic math that we all learn as undergrads, have little in common
regarding their skill sets.
I am not surprised that the power folks are still using Fortran; the
technology in power distribution moves much more slowly than the technology in
signal processing and the requirements for reliability are higher in power
because the consequences of failure are much more expensive.
Dr. Christopher S. Tocci
>>> >
>>> > I don't know! I am in the process of researching
>>> > ... I use the slogan "Read Fortran, write C".
>>
>>I suppose because Fortran is legible, and C isn't ? :-)
>>But what about the poor guys who then have to read the C you wrote ? :-)
>>
>>> > The perennial issue that arises has always been "Why
>>> > bother with Fortran at all?".
>>
>>Why not ?
>>It is a language with a fast learning curve for scientists, it's not
>>overloaded with features they do not need, they know it and can teach it
>>to their students. C after all is a glorified assembler.
>>
>>Somebody else added :
>>
>>> The beauty of fortran, from an engineering point of
>>> view, is that the mathematical structures of the language
>>> is closer to engineering formulae than most any other
>>> programming language.
>
>[snip]
>
support
>for portable visualization. EVERY very-high-level language designed for
>engineers and scientists (MathCad, Matlab, Gauss, Macsyma, Maple,
Mathematica,
>etc. etc.) has support for easy visualization of results. Fortran has ZIP.
>
add
>on to your Fortran compiler to do visualizations, but every one is
>incompatible with the next. So the big selling point of Fortran
>(cross-platform standardization) becomes moot the moment you add a
third-party
>visualization package.
>
chances
>to survive in the 21st century in more than a few supercomputer centers
(electrical
>engineering/signal processing) Fortran is basically extinct and I cannot
>remember a refereed journal article in this field in the last 10 years
using
>Fortan code. It's all Matlab and C now.
I couldn't agree with you on this extremely important point:
Fortran, as far as technical computations are concerned, is bar far the best
compilable language available!
However, with that said, I do use MAPLE, VisSIM and many other "more
realistic" languages commercially available to
get answers sometime during my business day! You see, Fortran, C, C++ and
the rest are basically economic disasters
for rapid application development.
All product success stories are highly dependent upon "time to market."
Consequently, rather than have everybody and companies
and customers pay for wheel reinventing for algorithmic thinking. Why not
develop another language (doesn't exist yet!) where
the user can concentrate on solving the problem directly and quickly without
writing, training, etc. with a lot of incompatible languages
with their ridiculous third party supporters. Some languages already are
attempting this feat (examples are MAPLE, Mathematica, MatLAB, IDL, VisSIM,
etc.). Many of them export either C or Fortran code for compilation. Some
of these companies are attempting to build their own compilers for direct
production of product.
THIS IS THE WAY TO GO PEOPLE...GET WITH IT!!!!!!!!
The days of funny looking code and fighting for third party compatibility
are (or should be) history! We are looking at the 21st century...when will
the market catch up with the basics of market, compatibility, cost, ease of
use, etc.????????
Chris
Richard Maine
> Many "very-high-level languages" are, in fact, written in a
> high-level language like C or LISP. I don't know of any that were
> written in Fortran.
Matlab was originally written in Fortran. It was subsequently redone,
but the original was in Fortran. I even used to have a copy of the
old Fortran code around here, but haven't seen it in a while.
--
Richard Maine
ma...@qnet.com
Robert Orban
ste...@lcam.u-psud.fr says...
>
>On 29 Sep 1998 23:44:18 GMT, Robert Orban <robe...@orbanxyxy.com> wrote:
>>In article
<Pine.OSF.3.95.98092...@poseidon.ifctr.mi.cnr.it>,
>>nos...@ifctr.mi.cnr.it says...
>>
>>It seems to me that Fortran's current huge weakness is total lack of
>>support for portable visualization. EVERY very-high-level language
>>designed for engineers and scientists (MathCad, Matlab, Gauss, Macsyma,
>>Maple, Mathematica, etc. etc.) has support for easy visualization of
>>results. Fortran has ZIP.
>
>EVERY is a very bold overstatement, and very-high-level language is not
>a very clear definition for me.
I'm not sure that I can state a really clean definition of "very high level
language," but their general characteristics seem to be an orientation towards
getting fast results by, among other things, dispensing with rigorous data
typing and the other safety features that are F95's strong suit. They also
tend to allow you to solve problems much more compactly than Fortran or
other high-level languages, and have a very rich set of built-in commands
that, in Fortran, would be implemented as subroutines. Several are oriented
towards using matrices as their elemental data structures.(F90's addition of
array operations was a first step in this general direction.) They almost
always have a one- or two-line command for making simple 2D and 3D graphs of
arrays. The first "very-high-level language" was probably APL (though,
admittedly, it lacked visualization). Many "very-high-level languages" are, in
fact, written in a high-level language like C or LISP. I don't know of any
that were written in Fortran.
They are mainly suited for smaller, research-type problems because, sooner or
later, their lack of safety features will come back to bite you if you are
trying to build very large codes.
>Neither Ada nor Pascal nor Modula have
>visualization stuff. Nor does C, for that matter, even though it may be
>a matter of taste and religion to call it a very-high-level language
>or even just a high-level language.
I call all of the above "high-level languages" in that they are one step above
assembler, like Fortran, the first "high-level language."
Admittedly, none of the above do visualization. But none of the above are
advertised as the "language of science and engineering" either.
>
>>There are a lot of third-parties out there who will sell you a package
>>to add on to your Fortran compiler to do visualizations, but every one
>>is incompatible with the next. So the big selling point of Fortran
>>(cross-platform standardization) becomes moot the moment you add a
>>third-party visualization package.
>
>As does using Mathematica. My pet-OS is OS/2, Mathematica for that is
>seemingly frozen at version 2.2x, and the frontend is more or less text
>based. I heared that Maple has dropped OS/2 support as well or will do
>so. Many of the products you mentioned run on fewer platforms than
>fortran. However, nothing keeps you from creating your data with Fortran
>codes on the fastest hardware around (which may not even have graphics
>hardware, like the NEC vector supercomputer I use) and then visualize it
>with what ever tool you see fit, on which ever platform it requires.
Most of the work I do in Fortran is interactive and requires constant
visualization to guide me. (I write in Fortran because interpreted languages
are too slow.) I greatly prefer to stay within the Fortran environment (I use
PGPLOT for visualization at the moment) because (a) the visualization is much
easier to code than it would be in a mixed language environment, and (b) it is
likely to be faster in allowing one to obtain the visualization and then
to switch back to the command line. (b) is very important to me in an
interactive environment because latency interrupts the thought and creative
processes.
In this day and age it is highly probable that the user has a graphics
terminal of some sort available. There are a number of common standards around
(everything from the old Tektronix PLOT10 to open GL) that could, at least,
provide a starting point for discussion.
>
>>chances to survive in the 21st century in more than a few
>>supercomputer centers where its support for parallel processing is
>>useful. In my field (electrical engineering/signal processing) Fortran
>>is basically extinct and I cannot remember a refereed journal article
>>in this field in the last 10 years using Fortan code. It's all Matlab
>>and C now.
>
>Uff. I don't know your background but that statement surprises me. To
>some extent it is also at variance with what others here say and do for
>a living.
I was referring very specifically to the field of signal processing,
considered a specialty within electrical/electronic engineering.
>
>Finally, that you "... cannot remember a refereed journal article in
>this field in the last 10 years using Fortan code..." only says that
>either you simply cannot remember, or that you read a very selective
>group or even a small number of papers, or that simply nobody bothers to
>tell you what language they used unless they used Matlab or C.
>Certainly, for some hardware control applications C seems more
>appropriate, while for some energy flow modeling or other number
>crunching Fortran may be the better tool
Many academic signal processing papers provide small codes. In the signal
processing field the overwhelming favorites seem to be either pseudocode or
Matlab. Because it is important in the field to explicitly describe algorithms
(that's mostly what the field is about), one tends to see more algorithms
"spelled out" than one would in the general world of science, where papers
might range anywhere from theoretical results expressed as pure mathematics to
data reduction on measurements, where the results of the data reduction are
more important than the "plumbing" used to do the reduction.
LC's No-Spam Newsreading account
> On 29 Sep 1998 23:44:18 GMT, Robert Orban <robe...@orbanxyxy.com> wrote:
> >In article <Pine.OSF.3.95.98092...@poseidon.ifctr.mi.cnr.it>,
> >nos...@ifctr.mi.cnr.it says...
> >
> >It seems to me that Fortran's current huge weakness is total lack of
> >support for portable visualization.
SURELY I DID NOT SAY ANYTHING LIKE THAT from nos...@ifctr.mi.cnr.it !
Please check the original article !
Actually I fully endorse what Stefan A. Deutscher says, that is :
- if paper are on physics (or astrophysics, for me) surely they do not
refer explicitly to the programming language of the s/w. They may do
in a s/w conference (I did, for a largish package, in Fortran of course)
- "visualization" (I assume you mean plotting and so on) is not
standardized in any language (or should I say in "many" languages ?)
in astronomy people usually use "environments" like MIDAS or IRAF,
which provide their own programming (scripting) languages, but allow
integration of Fortran modules ; or may use for visualization a
language like IDL (which is quite Fortran-like in syntax ... it is
also nice as a development tool, since it is interpreted, to test
several algorithms ... and then write the production code in Fortran)
Stefan A. Deutscher
>
>ro> It seems to me that even a fairly elementary set of visualization in-
> structions, added to the standard, would greatly improve Fortran's chances
> where its support for parallel processing is useful.
>
>results on the same platform as I'm doing my number-crunching?
Well, one advantage of real-time visualization I can see: You can _see_
immediately whether a computation converges or goes off track and needs
to be restarted with different parameters. This may save valuable CPU
cycles, important especially when you're CPU limited or paying for time.
However, that said, I prefer to call gnuplot (or what ever) on
intermediate data, be it with an -- already pretty non-portable --
statement along the lines of
call system('gnuplot plotfile.gpl &')
or linking to some external graphics library. More often than not I use
plain vt100 terminal connexions where fancy graphics wouldn't do much
good.
>Let Fortran generate the data and dump it out; I'll use my cheap
>workstation to make pretty pictures ins
As someone else said: If you have the luxury of more than one machine. I
do, but many don't.
Cheers, Stefan
>-- Gary Strand stra...@ucar.edu
>http://www.cgd.ucar.edu/ccr/gary
Stefan A. Deutscher
>In article <slrn714fa2....@ferrari.lcam.u-psud.fr>,
>ste...@lcam.u-psud.fr says...
>>On 29 Sep 1998 23:44:18 GMT, Robert Orban <robe...@orbanxyxy.com> wrote:
>>>In article
><Pine.OSF.3.95.98092...@poseidon.ifctr.mi.cnr.it>,
>>>nos...@ifctr.mi.cnr.it says...
>>>It seems to me that Fortran's current huge weakness is total lack of
>>>support for portable visualization. EVERY very-high-level language
>>>designed for engineers and scientists (MathCad, Matlab, Gauss, Macsyma,
>>>Maple, Mathematica, etc. etc.) has support for easy visualization of
>>>results. Fortran has ZIP.
>>EVERY is a very bold overstatement, and very-high-level language is not
>>a very clear definition for me.
>I'm not sure that I can state a really clean definition of "very high level
>language," but their general characteristics seem to be an orientation towards
>getting fast results by, among other things, dispensing with rigorous data
[ snip]
Thanks for the clarification.
>>Neither Ada nor Pascal nor Modula have visualization stuff. Nor does
>>C, for that matter, even though it may be a matter of taste and
>>religion to call it a very-high-level language or even just a
>>high-level language.
>I call all of the above "high-level languages" in that they are one
>step above assembler, like Fortran, the first "high-level language."
Okay, as I said, it's a matter of taste and religion. I use Fortran and
C, besides awk, Pascal, Mathematica, Maple etc. I was just making
reference to a comment from a friend of mine who is very devoted C
programmer and refers to his pet language as 'high-level assembler'.
[ snip ]
>>However, nothing keeps you from creating your data with Fortran codes
>>on the fastest hardware around (which may not even have graphics
>>hardware, like the NEC vector supercomputer I use) and then visualize
>>it with what ever tool you see fit, on which ever platform it
>>requires.
>Most of the work I do in Fortran is interactive and requires constant
>visualization to guide me. (I write in Fortran because interpreted
>languages are too slow.) I greatly prefer to stay within the Fortran
>environment (I use PGPLOT for visualization at the moment) because (a)
>the visualization is much easier to code than it would be in a mixed
>language environment, and (b) it is likely to be faster in allowing one
>to obtain the visualization and then to switch back to the command
>line. (b) is very important to me in an interactive environment because
>latency interrupts the thought and creative processes.
Right. I can see the need for interactive work, I have it myself.
Believe it or not, since I never bothered to spend much time learning
much about X programming I still use a code written in Turbo-Pascal 6.x
(!) for some of my graphics stuff. I think a library such as Interacter
would do the trick for Fortran programmers much better than built-in
language primitives. Interacter is, AFAIK, available for many UNIX and
some Intel platforms (including Windoze and OS/2), and includes to the
best of my knowledge graphing as well as menu stuff, list boxes etc.
I can't find their URL right now, alas, but one of the fellows from the
company that make Interacter reads this newsgroup aparently.
>>Like what? Draw a line? A pixel? What if your output device can't do
>>pixels or lines? This would enter a world of hardware dependent driver
>>issues, just check out the gnuplot distribution to see how they handle
>>the various terminals. The only common denominator seems to be to
>>print stuff to a terminal (or printer of file), along the lines of
>>gnuplot's dumb terminal:
[ example snipped ]
>>but that you can really do already with gnuplot or with a few small
>>subroutines which IMHO don't belong in a language spec.
>In this day and age it is highly probable that the user has a graphics
>terminal of some sort available. There are a number of common standards
>around (everything from the old Tektronix PLOT10 to open GL) that
>could, at least, provide a starting point for discussion.
As I said in an earlier post, I still use vt100 (or at times even an
ancient televideo!) terminals to check on my codes, and I know many
people who do. Especially at universities the equipment varies widely,
which is a nice way to say it is often totally outdated, and researchers
prefer to put money in things they consider more essential than the
latest computer parts.
Also, many people I know access bigger machines through some terminal
emulation software from boxes running typical PC operating systems like
DOS, Windoze, OS/2, BSD what not. (I think even Craig Burley, the main
force behind g77 coding, used Linux w/o X for a very long time.) Anyway,
with exception of X emulators (like eXceed) or BSD, Linux, and OS/2
machines running real XFree86, these people have very limited graphics
capabilities.
I think that Kermit for MS-DOS can do Tektronix 401x, as do a few other
commercial products, but there are not many and they are not common. The
same with OpenGL, it is a relatively new standard, not supported on
every platform / OS / hardware. You would really open a can of worms.
The list of various gnuplot terminal drivers is long for a reason, and
only the PostScript and the X and PM terminals have advanced features.
Coding to the largest common denominator may still mean coding to a dumb
ascii terminal if you want your code to remain portable.
>>>In my field (electrical engineering/signal processing) Fortran is
>>>basically extinct and I cannot remember a refereed journal article in
>>>this field in the last 10 years using Fortan code. It's all Matlab
>>>and C now.
>>Uff. I don't know your background but that statement surprises me. To
>>some extent it is also at variance with what others here say and do
>>for a living. Finally, that you "... cannot remember a refereed
>>journal article in this field in the last 10 years using Fortan
>>code..." only says that either you simply cannot remember, or that you
>>read a very selective group or even a small number of papers, or that
>>simply nobody bothers to tell you what language they used unless they
>>used Matlab or C. Certainly, for some hardware control applications C
>>seems more appropriate, while for some energy flow modeling or other
>>number crunching Fortran may be the better tool
>I was referring very specifically to the field of signal processing,
>considered a specialty within electrical/electronic engineering. Many
>academic signal processing papers provide small codes. In the signal
>processing field the overwhelming favorites seem to be either
>pseudocode or Matlab. Because it is important in the field to
>explicitly describe algorithms (that's mostly what the field is about),
>one tends to see more algorithms "spelled out" than one would in the
>general world of science, where papers might range anywhere from
>theoretical results expressed as pure mathematics to data reduction on
>measurements, where the results of the data reduction are more
>important than the "plumbing" used to do the reduction.
I see. Thanks for the clarification again. So it means essentially that
indeed "...you read a very selective group ... of papers ...", like most
of us do. I am glad I worded my statement the way I did and I certainly
hope I didn't offend you.
By the way, is the field of signal processing a field large enough to
justify addition of graphics stuff to Fortran? If so, nothing prevents
the lobby to enter the next Standard meetings, but I feel it would be
difficult to implement even if it was met with enthusiasm.
Kind regards,
Carlie Coats
Robert Orban <robe...@orbanxyxy.com> wrote:
[Btw, Robert, would you please learn to follow Internet etiquette
and format your posts within 68 or so columns, so that even after
quoting they can be reasonably sure of staying on screen? Having
to re-format the quotes because of this is a pain.]
[snip: Mathematica is too slow for all except small problems.
C and Ada don't offer intrinsic vis support either]
> Most of the work I do in Fortran is interactive and requires constant
> visualization to guide me. (I write in Fortran because interpreted
> languages are too slow.) I greatly prefer to stay within the Fortran
> environment (I use PGPLOT for visualization at the moment) because
> (a) the visualization is much easier to code than it would be in a
> mixed language environment, and (b) it is likely to be faster in
> allowing one to obtain the visualization and then to switch back
> to the command line. (b) is very important to me in an interactive
> environment because latency interrupts the thought and creative
> processes.
I do really think you're over-stating the difficulty of mixed-language
programming.
But what I really think you want is provided by the latest generation
of X-based GUI debuggers. With these, you very nearly have a vis tool
embedded in the debugger. You can choose which portion of your code
to optimize to the hilt, and which portion not to (if speed in
computational kernels is a problem), and then stop the code wherever
you want to (at least within the "-g" parts) and visualize what is
going on using the _debugger's_ facilities (which don't have to be
part of the language.) This is much closer to the "interactive...
requir[ing] constant visualization" than you can reasonably get by
programming it *within your program* yourself.
I don't want to offend any vendors here by missing their products,
but here would be a good time for them to chime in so that we can
build a complete list. I myself have used such capabilities on SGI's.
What other vendors have such capabilities?
Carlie J. Coats, Jr. co...@ncsc.org
MCNC Environmental Programs phone: (919)248-9241
North Carolina Supercomputing Center fax: (919)248-9245
3021 Cornwallis Road P. O. Box 12889
Research Triangle Park, N. C. 27709-2889 USA
"My opinions are my own, and I've got *lots* of them!"
Joe Mortzheim
> >The perennial issue that arises has always been "Why bother with Fortran at
> >all?". I would value your comments on this subject.
> >
> >Thank you,
> >
> >Pls respond to: h...@engr.ucf.edu
> >
> >--
> >Prof. Harley R. Myler
>
> I find that an interesting question. I am an engineer myself. There are
> several hundred engineers in the organization I work for. I find that very
> few of them are very good at programming ( in any language ). I think that
> part of the reason for this is that most engineers are not programmers. They
> haven't spent the time ( nor will they ) learning good programming skills and
> techniques.
<snip>
I think you've hit the nail on the head with that statement. I am a
biometrician. I am continually writing code for everything from simple mathmatical
manipulation to pretty complex statistical analysis. For statistics I use S+, an
interpreted language type environment statistics (not without its own faults). For
everything else I use whatever is at hand at the time, usually this means Fortran.
Frankly I hate Fortran (sorry folks...don't have me tarred and feathered). I
find it clunky and annoying and my programs (no matter what their eloquent work in
the background) usually appear to the user as a sloppy looking command line window
type display. But I use Fortran precisely because I am not an expert programmer.
For my purposes, it is enough that the code actually does what I want it to without
me expending too much time in development. I like to use the best "programming
style" I can, but good programming is definitely a second priority after producing
results. Thus, for the moment it seems Fortran is the choice of the technician
seeking a quick and dirty answer to a mathmatical/statistical question.
I certainly hope this changes in the future. Perhaps as mixed language
programs get easier to handle. I think many of us out there are looking to a
Visual Basic front end and a Fortran engine as the silver bullet to our programming
problems. I myself would rather study in great detail a different language (such
as C++) and and quit using Fortran. However, mountains may crumble to the sea
before I have to time to properly learn a language to any great depth.
So for the moment you may count legions of non-programmers (or
pseudo-programmers?) as some of the biggest reasons why Fortran persists and will
continue to persist. Ironic, no?
Well you got my opinion for free and it may be worth exactly what you paid for
it. Thanks for being an environment for discussion.
Joe
Gary Strand
gs> Gary Strand
gs> Why would I want to waste valuable CPU seconds visualizing intermediate
results on the same platform as I'm doing my number-crunching?
sd> Well, one advantage of real-time visualization I can see: You can _see_
immediately whether a computation converges or goes off track and needs
to be restarted with different parameters. This may save valuable CPU
cycles, important especially when you're CPU limited or paying for time.
Possibly. Or it could be that the cost of decent visualizations that tell
you what you'd like to know is too high, or, as is most common, you don't
know what to look for until you've seen it.
All in all, save the supercomputers for big jobs, pass off everything else.
Sebastiano Barbieri
> biometrician. I am continually writing code for everything from simple
> mathmatical manipulation to pretty complex statistical analysis. For
> statistics I use S+, an interpreted language type environment statistics
> (not without its own faults). For everything else I use whatever is at hand
> at the time, usually this means Fortran.
Well, I'm an astrophysicist. Most colleagues of my age (~40) do program
more or less decently (some pretty good) in Fortran. Older (and often
younger) colleagues don't. They often use big packages which provide
their own scripting (or full programming) language.
For quick and dirty things you might consider use of IDL (if you can
afford the cost of a license).
> Frankly I hate Fortran (sorry folks...don't have me tarred and feathered). I
> find it clunky and annoying and my programs (no matter what their eloquent work in
> the background) usually appear to the user as a sloppy looking command line window
> type display.
From what you say it looks to me you are : (1) underestimating yourself ;
(b) you will hate much more a language like C.
> For my purposes, it is enough that the code actually does what I want it to
Well, that's should be the purpose of all programs.
And that's what most of the programs (mostly Fortran) written by us
scientist do. While those program written by software engineers maybe in
object oriented C++ usually don't (like a famous exposure calculator missing
exposure times by orders of magnitude, or those programs which get confused
near the poles of the celestial sphere :-( )
James Giles
> Many "very-high-level languages" are, in fact, written in a
> high-level language like C or LISP. I don't know of any that were
> written in Fortran.
Both C and LISP were originally conceived as low-level languages
that would be easy to port and provide a programming environment
in which to write higher-level languages and applications. I have a
paper somewhere in which John McCarthy expresses his continued
surprise that people chose to write code directly in LISP rather
than a higher-level language or a preprocessor.
The reason that many "very-high-level" languages are written in C and
LISP is the same as the reason that many compilers for languages of all
levels continue to be written in assembly: you need a low-level language
to implement a new language efficiently.
Having said that, I believe that I'd prefer to write a compiler in LISP
to writing one in C (though I've maintained compilers and interpreters
written in each of those languages).
--
J. Giles
James Giles
Joe Mortzheim wrote in message <361391AF...@snake1.cr.usgs.gov>...
...
> Frankly I hate Fortran (sorry folks...don't have me tarred and feathered). I
>find it clunky and annoying and my programs (no matter what their eloquent work in
>the background) usually appear to the user as a sloppy looking command line window
Well, it's a matter of taste I suppose (or age), but I prefer the command-line
interface for most things I use Fortran to do. Few applications actually
benefit from lots of buttons, slide-bars, drag-and-drop, etc.. In fact,
those features are a nuisance (take lots more time to write and debug,
but don't contribute to the speed, accuracy, or applicability of the code).
It's not just a matter of form over function, it seems to be the opinion of
many these days that the form *is* the function.
To be sure, good graphics is often essential. But many graphics packages
still in wide use today were originally intended as support for Fortran.
--
J. Giles
Toon Moene
> robe...@orbanxyxy.com (Robert Orban) writes:
> > Many "very-high-level languages" are, in fact, written in a
> > high-level language like C or LISP. I don't know of any that were
> > written in Fortran.
> Matlab was originally written in Fortran. It was subsequently redone,
> but the original was in Fortran. I even used to have a copy of the
> old Fortran code around here, but haven't seen it in a while.
Hmmm, speaking about useful old Fortran code; does anyone know where
Adventure lives these days ?
[ Visualisation is for people without imagination ]
--
Toon Moene (mailto:to...@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
g77 Support: mailto:for...@gnu.org; egcs: mailto:egcs...@cygnus.com
Robert Orban
ste...@lcam.u-psud.fr says...
[much snipped]
>
>By the way, is the field of signal processing a field large enough to
>justify addition of graphics stuff to Fortran? If so, nothing prevents
>the lobby to enter the next Standard meetings, but I feel it would be
>difficult to implement even if it was met with enthusiasm.
I believe that the requirement for graphics is far more general. If it were
not, it would not be a feature of virtually every "very-high-level language."
Not only is graphics a feature of such languages, but it is usually strongly
emphasized in their marketing materials.
As a first pass, I might suggest that Fortran graphic primitives could be
limited to a very simple set that would allow doing straightforward 2D and 3D
monochrome line plots on many terminals. Based on Tektronix syntax, the set
might include (off the top of my head):
WINDOW, VIEWPORT, AXIS, MOVE, DRAW, RELATIVE_MOVE, RELATIVE_DRAW, TEXT, ERASE.
I'm sure I left something crucial out, but, nevertheless one can do a great
deal with a small set like this. Of course, for 3D plots you would have to do
hidden line removal and the like with Fortran subroutines or modules.
I would expect that a public domain subroutine library would quickly appear
that used these primitives to create 2D X/Y plots and other commonly required
visualizations by just a few subroutine calls.
For folks who needed fancy color visualizations with area fills and such, this
set would be inadequate. In this case they could always use a non-portable
solution.
Robert Orban
>
>robe...@orbanxyxy.com (Robert Orban) writes:
>
>> Many "very-high-level languages" are, in fact, written in a
>> high-level language like C or LISP. I don't know of any that were
>> written in Fortran.
>
>but the original was in Fortran. I even used to have a copy of the
>old Fortran code around here, but haven't seen it in a while.
SPICE (not a language but a cornerstone program for circuit design and
analysis) was also originally written in Fortran (at Berkeley), but was
rewritten in C when version 3.x came out.
I would be interested whether there is any big, important program out there
that was ever ported the other way (from some other language into Fortran). I
can't think of one in my field.
I think that Fortran right now suffers from "bad marketing." This is why
people don't think of taking older C code and migrating it to F95 to gain the
advantages of F95's safety and good optimization. F95 is a modern, capable
language (as long as one doesn't want to do a chart, graph, or GUI ;-), but
many people still think of Fortran as F77 or even F66!
Dan Tex1
> Many "very-high-level languages" are, in fact, written in a
> high-level language like C or LISP. I don't know of any that were
> written in Fortran.
Personally... I have a hard time thinking of C as a high level language. If
assembly is consdered Low and Fortran is High, I think C would fit most
accurately into the Mid Level category.
Dan :-)
Dan Tex1
>> I think that Fortran right now suffers from "bad marketing." This is why
people don't think of taking older C code and migrating it to F95 to gain the
advantages of F95's safety and good optimization. F95 is a modern, capable
language (as long as one doesn't want to do a chart, graph, or GUI ;-), but
many people still think of Fortran as F77 or even F66! <<
That's kind of funny. Where I currently work, a project is just getting
underway to write a large package for bridge analysis and design. The powers
that be have decided the code will be written in C++. They site it's object
orientedness, reuse, portability, etc. They also think it is the defacto
language for writing programs which will operate under MS Windows. It's
"standard" graphics capabilities are also stated widely.
Well.. this software is going to be written by what are primarily bridge
designers ( I've seen some of their codes for simple stuff... very very scary
). I told them that I thought Fortran would probably be easier for these
non-programmer type engineers to write and maintain the resulting technical
code. I was told that Fortran arrays were too archaic and that data could not
be grouped together into data structures for easier use like it could in C++.
I was also told "point-blank" that the C++ code would run faster because C++
relies heavily on the more efficient practice of using pointers. I was also
told that Fortran was almost dead and that the code would be really hard to
support in a few years.
Oh well, how can I possibly argue with that kind of mentality?
Dan :-)
LC's No-Spam Newsreading account
> That's kind of funny. Where I currently work, a project is just getting
> underway to write a large package for bridge analysis and design. The powers
> that be have decided the code will be written in C++.
[...]
> I was told that Fortran arrays were too archaic and that data could not
[..]
> told that Fortran was almost dead and that the code would be really hard to
> support in a few years.
>
> Oh well, how can I possibly argue with that kind of mentality?
Well, in *your* country they do sell freely fire arms, don't they ? :-)
Stefan A. Deutscher
>In article <slrn716mg9....@ferrari.lcam.u-psud.fr>,
>ste...@lcam.u-psud.fr says...
>
>[much snipped]
>
>>
>>justify addition of graphics stuff to Fortran? If so, nothing prevents
>>the lobby to enter the next Standard meetings, but I feel it would be
>>difficult to implement even if it was met with enthusiasm.
>
>were not, it would not be a feature of virtually every "very-high-level
>language." Not only is graphics a feature of such languages, but it is
>usually strongly emphasized in their marketing materials.
Yes, because that is one of the features which set them apart from
numbercrunching languages. I am sure they don't emphasize in their
marketing materials that "With this language many tasks you can do in
seconds in Fortran will take you weeks!" :-)
And then, marketing information is not always the optimal guideline. Let
me quote a major software and bug distributor: "Where do you want to go
today?" They don't add the piece of information that would make it fair:
"We don't care. We can't even get you there tomorrow." :-)
>As a first pass, I might suggest that Fortran graphic primitives could be
>limited to a very simple set that would allow doing straightforward 2D and 3D
>monochrome line plots on many terminals. Based on Tektronix syntax, the set
^^^^^^^^^^^^^^^^
That's the culprit. Which ones, how many, etc. A library - written in
what ever language as long as it can be transparently linked to and
called from Fortran would do just that w/o bloating the language.
>might include (off the top of my head):
>
>WINDOW, VIEWPORT, AXIS, MOVE, DRAW, RELATIVE_MOVE, RELATIVE_DRAW, TEXT, ERASE.
>
>I'm sure I left something crucial out, but, nevertheless one can do a great
>deal with a small set like this. Of course, for 3D plots you would have to do
>hidden line removal and the like with Fortran subroutines or modules.
>I would expect that a public domain subroutine library would quickly appear
>that used these primitives to create 2D X/Y plots and other commonly required
>visualizations by just a few subroutine calls.
But to some extent you can do that already. AFAIK there is a gnuplot
library to which you can link, and from what I understand it does more
or less what you'd want.
>For folks who needed fancy color visualizations with area fills and
>such, this set would be inadequate. In this case they could always use
>a non-portable solution.
Really, I think the graphics stuff would be highly platform dependent,
and that may be why it is not in any portable language I know of. Sure,
IDL, Mathematica etc. can do it on a few platforms, but they are
proprietary systems with compilers written by one vendor. Such platform
dependent graphics statements as element of a Fortran Standard might
slow down the availability of compilers, commercial as well as GNU. I
really think inclusion of graphics primitives in Fortran is barking up
the wrong tree.
Cheers, Stefan
Craig Burley
> (I think even Craig Burley, the main
> force behind g77 coding, used Linux w/o X for a very long time.)
Yes, and have been doing the same for nearly a year now, simply
because I haven't had a strong-enough desire to figure out how to
re-create the decent X environment the Craftworks distribution
of Linux for the Alpha (which I was using for nearly a year,
previously) happened to provide me -- given how much I appreciate
the fast, mouseless switching of VCs.
(And, yes, I'm quite sure I *can* recreate that environment, with
as much of the performance necessary for me to feel comfortable,
given my current hardware...just haven't had the time, and figure
it'll go easier once I upgrade my various softwares anyway.)
My own personal usage, though, probably pertains little to this
discussion, since I don't do numerical work.
--
"Practice random senselessness and act kind of beautiful."
James Craig Burley, Software Craftsperson bur...@gnu.org
Craig Burley
> Stefan A. Deutscher wrote:
>
> > Nor does C, for that matter, even though it may be
> > a matter of taste and religion to call it a very-high-level language
> > or even just a high-level language.
>
> For a poster to clf to take this swipe at C requires a good deal of
> religion or else gross ignorance. Since you seem knowledgeable enough,
> I hope you put a big donation in the plate at Our Mother of the Holy
> Fortran.
Just because someone posts to c.l.f doesn't mean they don't understand
the issues!
C is less high-level than Fortran in at least a few ways. For example,
it doesn't have operators that correspond to Fortran's .AND. and .OR..
(What C provides in their stead are lower-level operators -- each
of which can be precisely specified in Fortran, but one cannot
specify Fortran's .AND. and .OR. directly in C.)
As another (and somewhat related) example, C doesn't have a construct
comparable to Fortran functions in terms of being high-level. Though
extensions to C, and confusion (even among interpretations of the
Fortran standard(s)) mitigate this somewhat, there's nothing
quite like `I = J * K()' in C, in the sense that, as expressed in
Fortran, the *only* purpose of that statement is to compute and assign
a new value for I -- whereas, the "same" code in C also has, as its
purpose, the execution of the K() function, even when J is 0. (A
Fortran implementation is permitted to skip calling K when J is 0,
at least.)
Note that "high-level" is not the same thing as "feature-laden". C
has some features FORTRAN 77 doesn't, not to mention many practical
advantages (which, among other things, explain why I do hardly any
coding in Fortran, and much in C). But it is more difficult to write
code in C that *avoids* expressing low-level details than it is in
Fortran, in cases such as the ones I've highlighted above.
And, in my experience, C advocates tend to consider these differences
to be advantages of C over Fortran (for example). And the convenience
of syntactic infix operators that express quite a bit about
implementation details surely makes C a more compact low-level language
than assembly, often at just, or nearly, the right "level" of low-level
detail mixed with high-level abstraction. (E.g. I've found the
`&&' and `||' operators to be well worth whatever lack of high-level
elegance they offer, simply becaues they're easy to type and to
recognize, though they can lead to easily writing confusing code.
The alternatives offered by languages such as Fortran and PL/I can
make for unnecessarily verbose code, especially in systems-level
programming.)
But, C advocates should not conclude that, simply because they find
C's particular "level" of expression adequate for their needs, C is
therefore a particularly "high"-level language. Heck, in no standardized
version of *Fortran* can the value of an irrational like PI be specified
in a high-level way, so, given that Fortran is a "number-crunching
language", it's not unreasonable to say that Fortran's isn't particularly
high-level, either!
In both cases, the programmers who tend to use them often find that
the areas in which the respective languages demand implementation
details tend to coincide with the areas in which they already have
worked out, or don't care too much about, those details. (E.g.
the precision to be used for numerical computations.) And, that the
languages permit sufficiently high-level expressions for less-nailed-
down aspects of their jobs to be considered "high-level" for their
purposes.
Stefan A. Deutscher
>sd> Stefan A. Deutscher
>gs> Gary Strand
>
>gs> Why would I want to waste valuable CPU seconds visualizing intermediate
> results on the same platform as I'm doing my number-crunching?
>
>sd> Well, one advantage of real-time visualization I can see: You can _see_
> immediately whether a computation converges or goes off track and needs
> to be restarted with different parameters. This may save valuable CPU
> cycles, important especially when you're CPU limited or paying for time.
>
> Possibly. Or it could be that the cost of decent visualizations that tell
> you what you'd like to know is too high,
Wouldn't visualization stuff in Fortran compilers also add to the cost
of decent compilers? Many use g77 for cost reasons. If the cost of
'decent visualization' is too high you're perhaps after something more
advanced than gnuplot / gle, in which case Fortran graphics primitives
will not do the trick w/o additional libraries or massive coding on your
part, either.
> or, as is most common, you don't know what to look for until you've
> seen it.
I know that phenomenon very well :-) I guess, every scientist does.
However, as long as you're digging around not exactly knowing what to
look for it is also difficult to tell in advance which part of your data
to visualize how. Again, I don't see why Fortran graphics primitives
would make that easier. In such cases, normally store as much data as I
can and then look at it in different ways, until I see what I am
interested in. Sometimes gnuplot will do, sometimes I need spyglass or
the IBM data explorer, but none of that I'd want to have to write
myself.
Stefan A. Deutscher
>In article <slrn716mg9....@ferrari.lcam.u-psud.fr>,
>ste...@lcam.u-psud.fr says...
>
>[much snipped]
>
>
>were not, it would not be a feature of virtually every "very-high-level
>language." Not only is graphics a feature of such languages, but it is
>usually strongly emphasized in their marketing materials.
>
>be limited to a very simple set that would allow doing straightforward
>2D and 3D monochrome line plots on many terminals. Based on Tektronix
>syntax, the set
One more point. I brought up Turbo-Pascal before. It came from DOS, had
lots of platform dependent features which were quite nice, and which
caused it to stay in the DOS / Windows world. It was a _pain_ to get
hires graphics with different graphics cards, standard VGA worked most
of the time, but often you needed to ship a load of drivers with a code.
There is a GNU effort for GNU Pascal going (gpc). It implements a
compiler which will eventually be compatible with the ANSI/ISO standards
for Pascal (1979?) and Extended Pascal (1989?). No graphics. Now, some
kind soul has begun adding Turbo/Borland Pascal compatibility stuff, but
graphics is still being handled in external routines and very platform
dependent.
These examples may serve to illustrate that it is going to be really
difficult to do graphics (other than ascii pseudo graphics) accross
machines, operating systems, hardware configurations.
Cheers, Stefan
Stefan A. Deutscher
>> Linux w/o X for a very long time.)
>
>I haven't had a strong-enough desire to figure out how to re-create the
>decent X environment the Craftworks distribution of Linux for the Alpha
>(which I was using for nearly a year, previously) happened to provide
>me -- given how much I appreciate the fast, mouseless switching of VCs.
>
>(And, yes, I'm quite sure I *can* recreate that environment, with as
>much of the performance necessary for me to feel comfortable, given my
>current hardware...just haven't had the time, and figure it'll go
>easier once I upgrade my various softwares anyway.)
>
>My own personal usage, though, probably pertains little to this
>discussion, since I don't do numerical work.
I know, nor did I doubt you'd be able to set up X should you be inclined
to do so. I just wanted to illustrate the point that UNIX or Linux does
not always mean X, and I picked a fellow known to probably everybody in
this group. I could have named a co-worker of mine (who actually can't
get X up on his hardware and hence gave up, using screen now), but who'd
know him? :-)
But, let me ask you as someone much closer than many of us to the
details of coding a fortran compiler, and to interpreting the standard
by the word yet having to add flexibility for common vendor extensions
or user expectations: What do you think about the whole graphics thing?
Cheers, Stefan
Joseph Landman
> These examples may serve to illustrate that it is going to be really
> difficult to do graphics (other than ascii pseudo graphics) accross
> machines, operating systems, hardware configurations.
I believe this not to be correct, especially if you use OpenGL and its
associated libraries. While adding in specific functionality to Fortran
and its derivatives may not make much sense, using existing toolkits
such as OpenGL (allows for 3D visualization) is not very hard and can be
quite platform independent if you use the higher level GLUT tool kits.
I believe OpenGL has Fortran (and F90) bindings, and the GLUT are just C
routines that you can call from Fortran (F90).
However, I usually argue that when you are going beyond simple I/O into
the creation of a user interface of a graphical nature, it is best to
reuse other peoples code whenever possible. This means often writing
the UI in C/C++ with the
GLUT/OpenGL/Inventor/Performer/Optimizer/Volumizer calls, and hooks back
into the Fortran compute engine to get data in and out. This is my own
philosopy on this, and it might not make sense to someone for whom
Gnuplot does an acceptable job. However, If you have more data than
Gnuplot allows for, or you need to visually interact with your
visualization, then you might need to consider such tools.
--
Joseph Landman, Ph.D, | 39001 West Twelve Mile Rd,
Systems Engineer, | Farmington Hills,
Silicon Graphics/Cray Research | MI 48331-2903
-------------------------------+---------------------------------
voice: +1 248 848 4469 email: lan...@sgi.com
fax: +1 248 848 5600 web: http://reality.sgi.com/landman
Stefan A. Deutscher
>Stefan A. Deutscher wrote:
>
>> These examples may serve to illustrate that it is going to be really
>> difficult to do graphics (other than ascii pseudo graphics) accross
>> machines, operating systems, hardware configurations.
>
>I believe this not to be correct, especially if you use OpenGL and its
>associated libraries. While adding in specific functionality to Fortran
>and its derivatives may not make much sense, using existing toolkits
>such as OpenGL (allows for 3D visualization) is not very hard and can be
>quite platform independent if you use the higher level GLUT tool kits.
>I believe OpenGL has Fortran (and F90) bindings, and the GLUT are just C
>routines that you can call from Fortran (F90).
But doesn't OpenGL require either X or some other windowing environment
with, well, OpenGL support? I am told Windows NT has OpenGL support, as
does OS/2 from version 4.x on, as do many UNICes, but what do I do with
my IBM Mainframe accounts, with many DOS machines, with Tektronix
terminals, vt terminals, printers capable of printing graphics etc.?
>However, I usually argue that when you are going beyond simple I/O into
>the creation of a user interface of a graphical nature, it is best to
>reuse other peoples code whenever possible. This means often writing
>the UI in C/C++ with the
>GLUT/OpenGL/Inventor/Performer/Optimizer/Volumizer calls, and hooks
>back into the Fortran compute engine to get data in and out. This is
>my own
I totally agree.
>philosopy on this, and it might not make sense to someone for whom
>Gnuplot does an acceptable job.
Better: "For tasks for which gnuplot does an acceptable job".
>However, If you have more data than Gnuplot allows for, or you need to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
That would be quite something. :-)
>visually interact with your visualization, then you might need to
>consider such tools.
You hit it on the head, as usual. It comes down to taking the right tool
for the job.
Cheers! Stefan
Jeff Templon
> Stefan A. Deutscher wrote:
> > Nor does C, for that matter, even though it may be
> > a matter of taste and religion to call it a very-high-level language
> > or even just a high-level language.
> For a poster to clf to take this swipe at C requires a good deal of
> religion or else gross ignorance. Since you seem knowledgeable enough,
> I hope you put a big donation in the plate at Our Mother of the Holy
> Fortran.
No. It only requires reading the Book Of All Books on C, which is
Kernighan and Ritchie's book. I quote directly from the second
edition (the ANSI C edition):
Page xi, "Preface to the First Edition"
C is not a "very high level" language, nor a "big" one, and
it is not specialized to any particular area of application.
But its absence of restrictions and its generality make it
more convenient and effective for many tasks than supposedly
more powerful languages.
Note: not a very high level language. The language's CREATORS said
this.
Page 1, "Introduction"
C is a relatively "low level" language. This characterization
is not pejorative, it simply means that C deals with the
same sort of objects that most computers do, namely characters,
numbers, and addresses.
It seems the creators thought C to be neither very high level nor
even high level.
JT
Joseph Landman
>
> On Fri, 02 Oct 1998 08:47:06 -0400, Joseph Landman <lan...@sgi.com> wrote:
> >Stefan A. Deutscher wrote:
> >
> >> These examples may serve to illustrate that it is going to be really
> >> difficult to do graphics (other than ascii pseudo graphics) accross
> >> machines, operating systems, hardware configurations.
> >
> >I believe this not to be correct, especially if you use OpenGL and its
> >associated libraries. While adding in specific functionality to Fortran
> >and its derivatives may not make much sense, using existing toolkits
> >such as OpenGL (allows for 3D visualization) is not very hard and can be
> >quite platform independent if you use the higher level GLUT tool kits.
> >I believe OpenGL has Fortran (and F90) bindings, and the GLUT are just C
> >routines that you can call from Fortran (F90).
>
> But doesn't OpenGL require either X or some other windowing environment
> with, well, OpenGL support?
X, Win32, BeOS, MacOS, ...
> I am told Windows NT has OpenGL support, as
> does OS/2 from version 4.x on, as do many UNICes, but what do I do with
> my IBM Mainframe accounts, with many DOS machines, with Tektronix
> terminals, vt terminals, printers capable of printing graphics etc.?
Client server... Write your code to open sockets or use MPI or PVM or
whatever to send data to the visualization process.
Realistically... are you using an IBM Mainframe for scientific
calculation??? (I did about 10 years ago, and getting data on and off
was a royal pain ).
Regardless of that, textronix terminals, VT terminals etc are not
visualization devices, they are fancy plotters at best (IMO). I am
talking about visualization which requires a great deal of information
passing back and forth, not necessarily a nice x-y plot... You could
use Gnuplot for that, and it will run nicely on those machines.
> >However, I usually argue that when you are going beyond simple I/O into
> >the creation of a user interface of a graphical nature, it is best to
> >reuse other peoples code whenever possible. This means often writing
> >the UI in C/C++ with the
> >GLUT/OpenGL/Inventor/Performer/Optimizer/Volumizer calls, and hooks
> >back into the Fortran compute engine to get data in and out. This is
> >my own
>
> I totally agree.
>
> >philosopy on this, and it might not make sense to someone for whom
> >Gnuplot does an acceptable job.
>
> Better: "For tasks for which gnuplot does an acceptable job".
>
> >However, If you have more data than Gnuplot allows for, or you need to
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That would be quite something. :-)
I did some energy level spectra stuff that Gnuplot couldnt handle (2
years ago). I had to redo it using other tools.
> >visually interact with your visualization, then you might need to
> >consider such tools.
>
> You hit it on the head, as usual. It comes down to taking the right tool
> for the job.
>
> Cheers! Stefan
>
> --
> =========================================================================
> Stefan A. Deutscher | (+33-(0)1) voice fax
> Laboratoire des Collisions Atomiques et | LCAM : 6915-7699 6915-7671
> Mol\'{e}culaires (LCAM), B\^{a}timent 351 | home : 5624-0992 5624-0992
> Universit\'{e} de Paris-Sud | email: s...@utk.edu
> 91405 Orsay Cedex, France (Europe) | (forwarded to France)
> =========================================================================
> Do you know what they call a quarter-pounder with cheese in Paris?
--
William F Mitchell
> I believe OpenGL has Fortran (and F90) bindings, and the GLUT are just C
> routines that you can call from Fortran (F90)
Yes, there are Fortran 90 bindings for OpenGL. The specification and a public
domain implementation of them are available at http://math.nist.gov/f90gl
This also contains the Fortran 90 interface for GLUT.
--
William F. Mitchell | william....@nist.gov
National Institute of Standards and Technology | na.wmi...@na-net.ornl.gov
If anything looks like an opinion, NIST does not necessarily agree with it.
If anything looks like an official NIST or government statement, it's not.
Jeremy Beal
>I do really think you're over-stating the difficulty of mixed-language
>programming.
I agree, I feel that use of Fortran for speed/simplicity critical
areas with something object oriented or more natural to
a GUI for higher level constructs can work very well.
Jeremy Beal
Get my e-mail address at www.nvmedia.com/jbeal
(Tired of the damn spam)
Craig Burley
> On 02 Oct 1998 06:08:59 -0400, Craig Burley
> <bur...@tweedledumb.cygnus.com> wrote:
> >ste...@lcam.u-psud.fr (Stefan A. Deutscher) writes:
> >
> >> (I think even Craig Burley, the main force behind g77 coding, used
> >> Linux w/o X for a very long time.)
> >
> I know, nor did I doubt you'd be able to set up X should you be inclined
> to do so. I just wanted to illustrate the point that UNIX or Linux does
> not always mean X, and I picked a fellow known to probably everybody in
> this group. I could have named a co-worker of mine (who actually can't
> get X up on his hardware and hence gave up, using screen now), but who'd
> know him? :-)
No problem...just wanted to clarify that I was *now* using Linux without
running X, but have used it with X as well. (I've also used NeXT,
Solaris -- mostly with OpenWindows, HP-UX, and the pre-version-6 MacOS,
among many other sorts of systems.)
> But, let me ask you as someone much closer than many of us to the
> details of coding a fortran compiler, and to interpreting the standard
> by the word yet having to add flexibility for common vendor extensions
> or user expectations: What do you think about the whole graphics thing?
Having used very primitive, rough equivalents of numerical visualization
tools in my own work (which is rarely numerical), I see tons of
advantages to that.
I have serious reservations about integrating particular visualization
facilities into new language design. In a way, even Fortran's FORMAT
goes "too far", due to mandating particular notational details at
the expense of those who'd prefer different ones. (Say, using periods
instead of commas or spaces to denote decimals.)
But, I am quite interested in having languages provide some integrated
access to higher-level visualization, interaction, reporting, and
diagnostic *concepts* that can be mapped (even at run time) to
arbitrary instantiations, which would also mean these instantiations
could be provided with the programs that invoke them by "default"
using the abstractions.
So, for example, a program could use this higher-level abstraction
to identify the key numerical components (or equations) to "plot"
at an abstract level, perhaps provide (or denote) one particular
instantiation -- such as a graph -- as a default, and yet allow
a user to substitute a different instantiation, even on a global,
system-wide level, such as an audio interface that represents
interactions of equations as different frequencies with different
tonalities changing over time (which might be preferred by blind
users).
I think most of my concerns pretty much are independent of specific
areas of interest, such as scientific/numeric computing, though
areas like this might be particularly useful in revealing just
what kinds of abstractions are necessary, etc.
One of my biggest concerns is that people exposed overmuch to
visualization tools might have less ability to express (communicate)
concepts that they visualize. "Y=X**2" isn't "visual", but
has a two-way communicative nature that the corresponding plot
does not, in that, once a particular reader learns to "recognize"
either form, "Y=X**2" is much more straightforward to communicate
to others than writing/sending the plot.
That may seem silly, but since my "personal" interest in visualization
tools pertains to issues such as how high-level code (like Fortran,
or even mathematical expressions or something) is transformed (often
via many independent transformations) into low-level code (like
assembler), I'm very concerned that each type of visualization and
interaction offers a clear, consistent way for the user to *input*
data (new data, modifications, and so on) that corresponds strongly
with how the output appears.
Given that, and given the sheer number of transformation layers
involved in the work I do, combined with the fairly dizzying number
of specific transformations, you can perhaps see why I don't just
"jump in" and start authoring distinct I/O models for each sort
of transformation, especially models assuming graphics, or text,
or audio/visual capability.
Because, with all those transformations suddenly being exposed,
instead of going on "behind the scenes" when one types "f77 foo.f"
or "gcc foo.c", a huge amount of new stuff will have to be "learned"
by the user unless some kind of underlying, binding, consistent
way of viewing those transformations (as multi-way objects) is
first discovered and then exploited to form the basis of the
manipulations offered to the user.
In other words, the danger I see is that, in trying to just go and
"do it", I'd make a system that is to regular expressions (a la
grep, sed, whatever) to regular expressions are to simple text
search: so byzantine that the only people who could practically
use it wouldn't need it anyway.
I would guess that this danger would show itself in a particular field,
such as visualization tools for scientific/numeric modelling, only
after years of success and accretion of new facilities to meet
user request, if ever. So I don't think it's a problem that is
necessarily going to occur in any particular field -- but I'm
pretty sure it will if the industry tries to find and promote
solutions that leverage commonalities across fields, from numerics
to symbolics to data bases to networks, etc.
Gary L. Scott
> Stefan A. Deutscher wrote:
>
> > These examples may serve to illustrate that it is going to be really
>
> > difficult to do graphics (other than ascii pseudo graphics) accross
> > machines, operating systems, hardware configurations.
>
> I believe this not to be correct, especially if you use OpenGL and its
>
> associated libraries. While adding in specific functionality to
> Fortran
> and its derivatives may not make much sense, using existing toolkits
> such as OpenGL (allows for 3D visualization) is not very hard and can
> be
> quite platform independent if you use the higher level GLUT tool kits.
>
> I believe OpenGL has Fortran (and F90) bindings, and the GLUT are just
> C
> routines that you can call from Fortran (F90).
>
> However, I usually argue that when you are going beyond simple I/O
> into
> the creation of a user interface of a graphical nature, it is best to
> reuse other peoples code whenever possible. This means often writing
> the UI in C/C++ with the
> GLUT/OpenGL/Inventor/Performer/Optimizer/Volumizer calls, and hooks
> back
> into the Fortran compute engine to get data in and out.
I've added GUI interfaces to several applications using three methods
(partly a learning exercise): 1) mixed language Fortran/C, straight C,
and Fortran/third party Fortran-targeted library). I can honestly say
that (on a Windows) platform it takes less than 1/3 of the time to
produce a full-fledged debugged/working GUI for a Fortran program using
a tool such as GINOMENU or Winteracter (or similar, I've only used these
2) as direct Win32 API calls in either Fortran or C. In fact,
development tends to be faster than Quickwin if you're doing fairly
sophisticated things (its hard to beat a key word on the OPEN statement
for opening a simple window). Some of these types of tools are highly
portable and probably provide all of the graphics primitives, plotting,
visualization facilities you would ever want. It also results in better
Fortran code (readability, understandability, no compiler directives,
unecessarily complex declarations (consistency of API design as opposed
to the Win16/32 hodgepodge), resource compiler optional (so that you can
package the way you want to), or extensions (to Fortran 90 and in some
cases Fortran 77). If you've never used one of these, you're really
missing out (wish they were less costly though).
Im not very familiar with OpenGL, but if it can achieve half what these
tools achieve, and truly be a widely adopted "standard", it would be
great (these libraries are mostly proprietary, although some are GKS
compliant).
> philosopy on this, and it might not make sense to someone for whom
> Gnuplot does an acceptable job. However, If you have more data than
> Gnuplot allows for, or you need to visually interact with your
> visualization, then you might need to consider such tools.
>
> --
> Joseph Landman, Ph.D, | 39001 West Twelve Mile Rd,
> Systems Engineer, | Farmington Hills,
> Silicon Graphics/Cray Research | MI 48331-2903
> -------------------------------+---------------------------------
> voice: +1 248 848 4469 email: lan...@sgi.com
> fax: +1 248 848 5600 web: http://reality.sgi.com/landman
--
Gary L. Scott
mailto:sco...@flash.net
Phillip Helbig
<bur...@tweedledumb.cygnus.com> writes:
> I have serious reservations about integrating particular visualization
> facilities into new language design. In a way, even Fortran's FORMAT
> goes "too far", due to mandating particular notational details at
> the expense of those who'd prefer different ones. (Say, using periods
> instead of commas or spaces to denote decimals.)
Coming up in Fortran is the concept of a `locale' which will allow such
behaviour to change. For example, many European languages swap commas
and decimals in numbers.
--
Phillip Helbig Email ......... p.he...@jb.man.ac.uk
Nuffield Radio Astronomy Laboratories Tel. .... +44 1477 571 321 (ext. 297)
Jodrell Bank Fax ................ +44 1477 571 618
Macclesfield Telex ................ 36149 JODREL G
UK-Cheshire SK11 9DL Web ... http://www.jb.man.ac.uk/~pjh/
My opinions are not necessarily those of NRAL or the University of Manchester.
Graham Kipp
We have a copy for VAX/Alpha systems which (I think) came from DECUS,
dated 1994. I don't have anything more recent than that.
Regards,
Graham Kipp
*****************************************************************
* email: psed_...@ozemail.com.au
* To reply, please remove _nospam from the email address
* Phone: (613) 9679-4077
* Fax : (613) 9679-4061
*****************************************************************
Toon Moene wrote in message <6v0kof$co1$2...@newnews.nl.uu.net>...
Stefan A. Deutscher
>Stefan A. Deutscher wrote:
>>
>> >Stefan A. Deutscher wrote:
>> >
>> >> These examples may serve to illustrate that it is going to be really
>> >> difficult to do graphics (other than ascii pseudo graphics) accross
>> >> machines, operating systems, hardware configurations.
>> >
>> >I believe this not to be correct, especially if you use OpenGL and
>> >its associated libraries. While adding in specific functionality to
>> >Fortran and its derivatives may not make much sense, using existing
>> >toolkits such as OpenGL (allows for 3D visualization) is not very
>> >hard and can be quite platform independent if you use the higher
>> >level GLUT tool kits. I believe OpenGL has Fortran (and F90)
>> >bindings, and the GLUT are just C routines that you can call from
>> >Fortran (F90).
>>
>> environment with, well, OpenGL support?
>
>X, Win32, BeOS, MacOS, ...
>
>> I am told Windows NT has OpenGL support, as does OS/2 from version
>> 4.x on, as do many UNICes, but what do I do with my IBM Mainframe
>> accounts, with many DOS machines, with Tektronix terminals, vt
>> terminals, printers capable of printing graphics etc.?
>
>Client server... Write your code to open sockets or use MPI or PVM or
>whatever to send data to the visualization process.
Again, I know it can be done and how, but I think it would leave a lot
of hardware and people using this hardware behind. And, once I use PVM I
can also visualize with something written in a very different language
than Fortran. What I see from those of my co-workers who use graphics
from within their DOS (!) compilers are really simple line plots, and
for everything else they use more appropriate tools.
>Realistically... are you using an IBM Mainframe for scientific
>calculation??? (I did about 10 years ago, and getting data on and off
>was a royal pain ).
I still do. It still is a royal pain. But it is for many things about
fast as the high-end UNIX machines from Sun, IBM, SGI, and HP that I
have access to, and it is much more stable. In fact, in the last five
years I have experienced no unscheduled downtime. Also, the I/O
bandwidth and access to periphery like huge tape libraries is rather
nice. Of course, I do all code development for the mainframe on UNIX and
then submit batch jobs. I use all they cycles on all the machines I can
get.
>Regardless of that, textronix terminals, VT terminals etc are not
>visualization devices, they are fancy plotters at best (IMO). I am
>talking about visualization which requires a great deal of information
>passing back and forth, not necessarily a nice x-y plot... You could
>use Gnuplot for that, and it will run nicely on those machines.
Exactly my point. But I really wouldn't write spyglass transform or
something like it again just because suddenly I could :-)
The question remains -- should graphics primitives be in the Fortran
language specs and how could this be made portable. Just seeing how long
it takes for f90 and later to catch on makes me wonder.
Cheers, Stefan
Jeremy Beal
wrote:
>It seems the creators thought C to be neither very high level nor
>even high level.
I find that the C syntax itself is fairly low level, while the C standard
library stretches "ANSI C" from this lower level to higher, more
abstract levels. (Higher than Fortran?)
P. Bernedo x???? A??? gmv/fcsd/oad
> I think you've hit the nail on the head with that statement. I am a
> biometrician. I am continually writing code for everything from simple mathmatical
> manipulation to pretty complex statistical analysis. For statistics I use S+, an
> interpreted language type environment statistics (not without its own faults). For
> everything else I use whatever is at hand at the time, usually this means Fortran.
I agree with you that people not trained as programmers will always need a tool that
is simple but powerful enough to solve most of their programming problems. Fortran
suits well this niche. The problem arises when the same people attempt to design a
large program involving several programmers, several libraries and evolving over
several years. If you want to build such complex systems efficiently you need to learn
about software engineering, and this involves much more than just learning a language,
even if it is as complex as C++. When you consider the problems involved with building
complex systems you may find that a language like C++ actually makes things easier by
taking care of some of the bookkeeping chores and allowing you to concentrate on the
problem you need to solve. If engineers (including myself) are to build big software
systems, the first requirement is to learn about software engineering principles, not
just another language. This has a much bigger impact on the final result than the
actual language that you are using.
--
Pelayo Bernedo
GMV at ESOC.
Murx
> The perennial issue that arises has always been "Why bother with Fortran at
> all?". I would value your comments on this subject.
>
Easy:
Apart from coding the inner loops directly in assembler,
an f90 compiler in combination with an f77 source usually produces
code, which is about as fast as it gets.
I found this especially true for vector-supercomputers, but it also holds true
for architectures which rely on pipelining or pseudo vectorization.
In principle it should be possible to achieve the same performance in C,
but the resulting (vectorizable) code wouldn´t look like C. It would look like a
c2f code.
And even if you do so, and compare the performance of the resulting optimized
codes,
you´ll find that the above combination is still ahead of C by some 5-10%.
Due to the more restricted language structure of fortran, an optimizing compiler
in general is able to
produce a higher optimized code.
But i wouldn´t use f77/90 for anything but heavy numbercrunching.
Heavy here relates to jobs which run of order day on some supercomputer.
And introducing grafik primitives sounds downright obscene.
With those types of problems you do I/O on a ramdisk.
And having written several Gbyte you feed the data into a commercial packet. e.g.
IDL
Christian Simmendinger
>
> Thank you,
>
> Pls respond to: h...@engr.ucf.edu
>
> --
> Prof. Harley R. Myler Whoever is a teacher
> Dept. of Electrical & Computer Engr. through and through takes all
> University of Central Florida things seriously only in relation
> Orlando, Florida 32816-2450 to his students--even himself.
> 407.823.5098(ofc)/823.5835(fax) --Friedrich Nietzsche
> http://macmyler.engr.ucf.edu (Beyond Good and Evil, 63).
--
BERTI RAUS.
LC's No-Spam Newsreading account
> Pelayo Bernedo
> GMV at ESOC.
> Joe Mortzheim wrote:
> > usually this means Fortran.
> I agree with you that people not trained as programmers will always need a
> tool that is simple but powerful enough to solve most of their programming
> problems. Fortran suits well this niche. The problem arises when the same
I won't call a sizable fraction of scientists and engineers a "niche" ...
> people attempt to design a large program involving several programmers,
> several libraries and evolving over several years. If you want to build such
> complex systems efficiently you need to learn about software engineering,
> and this involves much more than just learning a language, even if it is as
> complex as C++.
Oh yes ... like a primary intergovernment research organization (which
has just one "C" less than the place you work ... and too much C++ :-) ,
and is located a few hundred km southeast) which decided to develop a
web-based multi-instrument exposure time calculator, where the members of
the different instrument consortia all around Europe should contribute
their part. Well, apparently even the simplest HTML page in the thing is
not written as plain HTML but generated by a C++ program, and there is
a single huge 100-page long C++ program which generates them all, and
in which the different consortia have to put their hands even if just
to change a single label ...
... not surprisingly the thing misses the right exposure time by some
orders of magnitude
The sort of thing which happens when scientific programming is taken
out of the hands of scientists to be given to fashion-keen "professional"
programmers :-(
I hope you won't lose any satellite now that you code spacecraft control
s/w in C++. Did not use to, back at the time of MSSS (what was that
written into, Siemens Assembler ?)
Meine Gruesse nach Mathildenhoehe ...
Jean Vezina
>
>
> > I think you've hit the nail on the head with that statement. I am a
> > biometrician. I am continually writing code for everything from simple mathmatical
> > manipulation to pretty complex statistical analysis. For statistics I use S+, an
> > interpreted language type environment statistics (not without its own faults). For
>
> I agree with you that people not trained as programmers will always need a tool that
> is simple but powerful enough to solve most of their programming problems. Fortran
> large program involving several programmers, several libraries and evolving over
> several years. If you want to build such complex systems efficiently you need to learn
> about software engineering, and this involves much more than just learning a language,
> complex systems you may find that a language like C++ actually makes things easier by
> taking care of some of the bookkeeping chores and allowing you to concentrate on the
> problem you need to solve. If engineers (including myself) are to build big software
> systems, the first requirement is to learn about software engineering principles, not
> just another language. This has a much bigger impact on the final result than the
> actual language that you are using.
>
The posting doesn't specify clearly if the "Fortran" referred is
Fortran 95 or just the obsolete Fortran 77 standard. Fortran 95
modules are an ideal tool for team programming projects. By using
the encapsulation and information hiding principles, each programmer
can write his or her part of the system and the final program uses
all of these modules without unwanted side effects if the problem is
specified properly.
Concerning the general questions "Is Fortran dead" or the opposite
"How to salvage Fortran", an important point I have noticed is that
too many people still think that the evolution of the language stops
with Fortran 77. This is true especially for some occasional
contributors to this newsgroup.
A substantial number of questions asked in this newsgroup are
directed on requesting informations about Fortran 77, showing that
there is still an important portion of the Fortran user community
who haven't yet make the move to Fortran 90/95.
Promoting modern Fortran is therefore essential if we want to change
the perception about the language.
Regards,
Jean Vezina
N8TM
>From: Jean Vezina <jve...@ibm.net>
>
>there is still an important portion of the Fortran user community
>who haven't yet make the move to Fortran 90/95.
>
Not to mention an important portion of the Fortran vendor community, if moving
to Fortran 90 means making it safe to move outside the intersection of Fortran
77 and 95. One of the new compilers I have to deal with still doesn't even
support EXIT or automatic arrays, although DATE_AND_TIME has made an
appearance.
We had an on-line discussion a few months back in which it was agreed that
f90/95 require the ability to deal with zero length arrays in many situations
where that is useful, yet none of the Unix Fortrans available to me do that. I
hesitate to go into areas which become difficult to back out of in cases of
difficulty.
Tim Prince
tpr...@computer.org
Charles Crawford
new features of F90 can slow down our program by a factor of 2 -
sometimes 8. The problem seems to center around arguement passing and
memory allocation. More disturbing is the fact that the time penalty
offten depends on which compiler you use.
See http://www.cs.rpi.edu/~szymanski/OOF90/penalty.html
One of the main attractions of Fortran in the past has been that when
you compiled your old program on a new platform, it not only gave you
the same numbers, but it also ran as fast as you would expect given the
new system. That seems to be true with F90 but only if you stick to F77
features!
-- Chuck Crawford, Toronto
Carlie Coats
Charles Crawford <ccra...@interlog.com> wrote:
> I agree with the last statement. We are finding that using some of the
> new features of F90 can slow down our program by a factor of 2 -
> sometimes 8. The problem seems to center around arguement passing and
> memory allocation. More disturbing is the fact that the time penalty
> offten depends on which compiler you use.
> See http://www.cs.rpi.edu/~szymanski/OOF90/penalty.html
One thing that would be really nice if the vendors would supply it:
give us means to find out just what argument-passing mechanism is
being used. This might take the form of a compiler-flag that has
the general nature of:
-LIST="ALLOC,ARGS,..."
I don't know of any compilers with this feature (and would be glad to
hear of any which do). I'd like to encourage vendors to provide this
sort of functionality, so that I can *know* what is going on when I need
to, rather than trying to second-guess the compiler on the basis of
inadequate evidence.
Carlie J. Coats, Jr. co...@ncsc.org
MCNC Environmental Programs phone: (919)248-9241
North Carolina Supercomputing Center fax: (919)248-9245
3021 Cornwallis Road P. O. Box 12889
Research Triangle Park, N. C. 27709-2889 USA
"My opinions are my own, and I've got *lots* of them!"
Richard Maine
> One of the main attractions of Fortran in the past has been that when
> you compiled your old program on a new platform, it not only gave you
> the same numbers, but it also ran as fast as you would expect given the
> new system. That seems to be true with F90 but only if you stick to F77
> features!
Sorry, but I 100% disagree that this was true of f77. I think what
you were seeing is just that you (and others) had gotten used to the
timing idiocyncracies of f77 and almost automatically worked around
them. Perhaps you haven't had users come to you asking why the
trivial code
do 100 i = 1 , n
do 100 j = 1 , n
100 a(i,j) = 0.
seems to run forever when they move the code to their new supposedly
much faster machine. I have. I've even seen exactly that question in
this newsgroup. Us experienced f77'ers are just so used to this that
we know the inner DO loop should be the one running down the column.
Along with lots of other simillar questions about f77 performance.
Lets see, even back from the f66 days, I recall speeding up one
co-worker's program by a factor of 100 by making a trivial change in
his overlay structure. And there was the other co-worker who was
going to "improve" on an FFT routine by replacing it with a "quick and
dirty" version. The FFT version took 5 minutes or so. We pulled the
plug on his "quick and dirty" one after several hourts - other people
needed to use the machine.
If your f77 code always ran at the speed you expected, then all I can
say is that you must lead a charmed life.
And I recall that getting even close to the same numbers was quite a
challenge when we moved from out IBM 360 machine to a CDC back in the
early 70's. Getting the bloody code to compile at all on the new
machine was a challenge - that was before everyone became sensitized
to portability and standards issues. After all Microsoft...um...I
mean IBM will always take care of us, right? But, of course, that's
all behind us now. :-)
I don't think the tricks of getting performance from were
fundamentally different from learning what kinds of array argument
passing or whole array operations are likely to cause performance hits
in f90. There is new stuff to learn, and we haven't learned all of it
yet (anyway, I haven't). But I regard it as basically simillar -
learning the rules of thumb that tend to help you get good
performance.
--
Richard Maine
ma...@altair.dfrc.nasa.gov
Charles Crawford
F90. I am still bothered by the fact that at this point different
compilers seem to have different rules of thumb. If this persists it
will certainly be the end of my charmed life.
BTW in my one contact with a CDC machine the local CDC folks gave me a
list of differences between the CDC Fortran and the IBM one I was
migrating from.
Chuck Crawford, Toronto
N8TM
>
> Maybe there will emerge some rules of thumb for
>F90. I am still bothered by the fact that at this point different
>compilers seem to have different rules of thumb.
It's true that some vendors appear to have taken the attitude that performance
(or even perhaps reliability) matters only for pre-f90 source code. It's up to
us to some extent to show those vendors that improvement on this attitude could
make a difference to their business.
As for different rules of thumb:
My personal observation is that automatic loop fusion is a necessity and that
serious compiler builders are working towards this, at least for the simple
cases of equal length loops. Only a minority of the compilers I've seen
attempt to fuse loops or array assignments which differ in length even by
exactly 1. If performance is needed from the simpler compilers, the programmer
will need to adjust for equal length, which has been true of many f77 compilers
as well.
Compilers which allocate and deallocate temporary arrays each time they are (or
might appear to be) needed will always have performance problems at least some
of the time. A real commitment to Fortran has to involve a compiler which
searches for an opportunity to make these arrays re-usable e.g. allocate and
deallocate at the entry and exit of a function. It will be up to the
programmer to provide such opportunities.
Tim Prince
tpr...@computer.org