Starting to doubt fortran
Nom...@gmail.com
I was wondering if its a good idea to start learning to program
fortran and why?
is it better or faster than C??
thanks
Chris
Beliavsky
Your question too broad to give a meaningful answer. You could read
the recent thread here "Merits of Fortran". You could read about both
languages and try writing some simple programs, to see which language
you prefer. You could find out which language is used more often in
your profession or academic field, which is not determined entirely by
technical factors.
Nom...@gmail.com
well I'm going to do a physics degree next year, so in terms of number
crunching, I've heard fortran is a good choice to learn, and its
easier to write a mathmatical formula with, but fortran isn't as
widely used as C..........is fortran actually quicker than C??
Gary Scott
> Hi
> I was wondering if its a good idea to start learning to program
> fortran and why?
yes, it is a pretty decent language, easier to use for many things than
some other languages (each language has advantages and disadvantages).
It is still widely supported and improvements (standards revisions) are
actively developed. It isn't going away anytime soon and it suits a
wide set of application domains quite well. It is mostly
straightforward to learn but with some quirks and historical baggage
(true of most languages).
> is it better or faster than C??
maybe. Fortran's very design makes it easier to avoid inefficient code,
but you can hand tune just about any compiled language and approximate
any other language in terms of performance.
> thanks
> Chris
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
e p chandler
IMO you should learn at least the basics of several programming
languages. Even if you program in Fortran, more and more algorithms
are being described in C and more and more numerical programs are
being written in C. Likewise, if you are a C programmer, Fortran is
still the reference language for many numerical packages. [It probably
would not hurt to learn a bit of Algol, Pascal and 360 assembler
too. :-). I've had to deal with programs written in each of these, and
more!]
-- elliot
highegg
> crunching, I've heard fortran is a good choice to learn, and its
> easier to write a mathmatical formula with, but fortran isn't as
> widely used as C..........is fortran actually quicker than C??
Both C and Fortran are definitely good to learn if you intend to
write a number-crunching application.
The question which language is faster does not really make much sense
even if you specify compilers, because it's hard to tell whether or
not two Fortran and C codes (non-trivial) are equivalent. Both C and
Fortran compilers are usually able to do heavy optimizations.
I did some number-crunching programming in both C (actually a
conservative C++) and Fortran and found Fortran more productive. Not
immediatelly, though - the prior exposure to C probably made me too
obsessed about performance and I was afraid of features that may carry
some performance penalty, like assumed-shape arrays, array expressions
and array-valued functions, pointers and allocatables etc. My style
was thus more like Fortran 77 enhanced with modules and simple derived
types. I sometimes call this the "F86 style" ( 86 = (77+95)/2 ) I
think it is good that Fortran still allows such programming and one
can resort to it should it be necessary.
Eventually (and partly thanks to this forum) I learned the Truth that
premature optimization is the root of all evil - I now use much more
modern Fortran features happily and the programming feels much like
Matlab, except that you have to declare and allocate the arrays (the
automatic F2003 allocation will save me some effort) and most of the
library isn't there; OTOH, it has the benefits of a compiled language.
This style greatly facilitates writing of quick throw-away programs.
IMHO, Fortran is not at all a language for writing superfast tuned
code (after all, C can be much better tuned than Fortran) but rather a
language that allows producing very fast (but not fastest) numerical
code easily.
I would not mind having all numerical libraries (BLAS,LAPACK,FFT etc.)
written in C provided that I can call them from Fortran conveniently.
I think that the Fortran standrads people did excellent job by
accepting that much numerical code is (and will be) written in C and
standardizing C interoperability.
Jaroslav
Lane Straatman
"e p chandler" <ep...@juno.com> wrote in message
news:1174841122....@o5g2000hsb.googlegroups.com...
> On Mar 25, 11:27 am, "Noma...@gmail.com" <Noma...@gmail.com> wrote:
>> Hi
>> I was wondering if its a good idea to start learning to program
>> fortran and why?
>> is it better or faster than C??
Development time may be different.
> IMO you should learn at least the basics of several programming
> languages. Even if you program in Fortran, more and more algorithms
> are being described in C and more and more numerical programs are
> being written in C. Likewise, if you are a C programmer, Fortran is
> still the reference language for many numerical packages. [It probably
> would not hurt to learn a bit of Algol, Pascal and 360 assembler
> too. :-). I've had to deal with programs written in each of these, and
> more!]
I think a person wants to put his finite resources in this regard in
languages that are becoming more relevant, which is what I see happening
with fortran.
BTW, I've got ibm1130.zip on my desktop without much of an idea what a
person is supposed to do with an emulator.
--
LS
Gary Scott
I think it more significant that OS APIs wil be more easily accessible.
>
> Jaroslav
e p chandler
> "e p chandler" <e...@juno.com> wrote in messagenews:1174841122....@o5g2000hsb.googlegroups.com...> On Mar 25, 11:27 am, "Noma...@gmail.com" <Noma...@gmail.com> wrote:
> >> Hi
> >> I was wondering if its a good idea to start learning to program
> >> fortran and why?
> >> is it better or faster than C??
>
> Execution is blindingly fast for both languages.
> Development time may be different.
>
> > IMO you should learn at least the basics of several programming
> > languages. Even if you program in Fortran, more and more algorithms
> > are being described in C and more and more numerical programs are
> > being written in C. Likewise, if you are a C programmer, Fortran is
> > still the reference language for many numerical packages. [It probably
> > would not hurt to learn a bit of Algol, Pascal and 360 assembler
> > too. :-). I've had to deal with programs written in each of these, and
> > more!]
>
> I think a person wants to put his finite resources in this regard in
> languages that are becoming more relevant, which is what I see happening
> with fortran.
I certainly don't program in Fortran and C with equal proficiency. I
prefer Fortran. YMMV.
> BTW, I've got ibm1130.zip on my desktop without much of an idea what a
> person is supposed to do with an emulator.
> --
> LS
Run old programs, just for fun. A while ago, I pointed out some source
code written for IBM 360 that was ported to the PDP-11 so that one of
the 1130 emulator maintainers could port it backwards to the IBM 1130.
It prints out a calendar with the type of line printer art that was
once popular in the late 60s - early 70s. see
http://en.wikipedia.org/wiki/IBM_1130/snoopy_calendar
Not only is this type of art archtypical of that produced by computer
"nerds" at the time, but it also is yet another example of how to deal
with characters without having *character* variables. At that time,
characters were stuffed into other data types, typically integers. How
they were packed and how they were manipulated was, of course,
specific to the particular computer, hence porting such programs is
either an interesting exercise or a real pain, depending on your point
of view. :-). Another example of primitive character handling would be
one of the various text computer games popular at the time such as
"Adventure" or "Star Trek". [see alt.folklore.computers for more
details]
So, to answer your question - running software under emulation is
partially of historical interest. From time to time it may be of help
in porting old programs to more recent architectures. See some
archived discussions here along the lines of "What does this old (CDC
or was it Cyber) Program do?"
Note that there is a reference on ibm1130.org to a firm that still is
running its business software in 1130 emulation mode. Also IIRC, one
of the key marketing features of the then new IBM 360 line, which was
supposed to end, and did end, at least for IBM, the "tower of babel"
proliferation of different and incompatible computer systems, was the
ability to run code written for older systems under emulation.
[Old hardware and software has a surprisingly long life. Not that long
ago some of the American computer systems used for air defense relied
on vacuum tubes that were no longer produced in the USA. Instead, they
had to be obtained from factories in the Eastern Block or the (former)
Soviet Union!]
-- elliot
blm...@myrealbox.com
English-language-usage nitpick: "Starting to doubt fortran" will be
read by many native speakers as "starting to think fortran is no good",
which I think isn't what you mean. I notice that many non-native
speakers use "doubt" in contexts in which I think most native speakers
(in the US anyway) would use "question". My guess is that this has
something to do with imperfect translation from the speaker's first
language (words don't always map one-to-one between languages).
Anyway, "doubt" has a generally negative connotation (you think
something is not true, or not good, or something) that's counter
to what I think you meant to say here.
OT and possibly unneeded, since you're getting answers to your
actual question. But based on the subject line, I thought your
post was going to be about how you thought Fortran really is dead,
despite the claims of many in this newsgroup, and that there would
then be a more-heat-than-light discussion.
"For what it's worth", maybe.
(I think I'd have used "should I learn fortran?" as a subject line.
Again, for what it's worth.)
--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
Tim Prince
> Nom...@gmail.com wrote:
>
>> Hi
>> I was wondering if its a good idea to start learning to program
>> fortran and why?
>
> yes, it is a pretty decent language, easier to use for many things than
> some other languages (each language has advantages and disadvantages).
> It is still widely supported and improvements (standards revisions) are
> actively developed. It isn't going away anytime soon and it suits a
> wide set of application domains quite well. It is mostly
> straightforward to learn but with some quirks and historical baggage
> (true of most languages).
>
>> is it better or faster than C??
>
> maybe. Fortran's very design makes it easier to avoid inefficient code,
> but you can hand tune just about any compiled language and approximate
> any other language in terms of performance.
>
takes longer to get right, and is ugly enough that some experts in those
languages are vociferous against it. For example, the use of const and
C99 restrict qualifiers in C. restrict is supported in C++ only by
non-standard extensions. You get the effect for free in Fortran.
Louis Krupp
I'm not sure I'd say that Indians (who I've seen using "doubt" as a
synonym for "question") aren't native speakers. English might not be
their mother tongue (there are hundreds of languages there), but it's a
common language in India. People seem to learn English very early, only
with a slightly different vocabulary and verb preference than in Britain
or North America. I get the impression that Indians use English to
communicate with each other as much as with foreigners, and if they all
learn the same usage of "doubt," then the rest of us might as well get
used to it.
Louis
blm...@myrealbox.com
Louis Krupp <lkr...@pssw.nospam.com.invalid> wrote:
> blm...@myrealbox.com wrote:
> > In article <1174836437.9...@l77g2000hsb.googlegroups.com>,
> > Nom...@gmail.com <Nom...@gmail.com> wrote:
> >> Hi
> >> I was wondering if its a good idea to start learning to program
> >> fortran and why?
> >> is it better or faster than C??
> >
> > English-language-usage nitpick: "Starting to doubt fortran" will be
> > read by many native speakers as "starting to think fortran is no good",
> > which I think isn't what you mean. I notice that many non-native
> > speakers use "doubt" in contexts in which I think most native speakers
> > (in the US anyway) would use "question".
[ snip ]
> I'm not sure I'd say that Indians (who I've seen using "doubt" as a
> synonym for "question") aren't native speakers. English might not be
> their mother tongue (there are hundreds of languages there), but it's a
> common language in India. People seem to learn English very early, only
> with a slightly different vocabulary and verb preference than in Britain
> or North America. I get the impression that Indians use English to
> communicate with each other as much as with foreigners, and if they all
> learn the same usage of "doubt," then the rest of us might as well get
> used to it.
Oh dear. What, it wasn't enough to have the US and the UK be "two
countries separated by a common language"? we need more variants?
Sort of a :-).
I actually was thinking, in writing my post, that I wouldn't want to
make any claims about all native speakers of English, only for those
in the US, and to word things accordingly. I hope that came across.
I'm interested to learn that this use of "doubt" for "question" is
not limited to non-native speakers (which is mostly where I think
I've encountered it before). Perhaps it will be interesting to the
OP to hear how his/her words were interpreted by a native speaker
of another dialect. Or something.
Terence
Physicist.
And certainly never as an undergraduate studying for a degree.
I doubt it would be in the syllabus. Certainly not in my time.
But as a mathematician I use it a lot, especially for problem solving
and statistics.
Those undergraduates I taught Fortran to (a long time ago) seem to
have mainly been chemists and electrical power engineers, and those
taking computer science in some form.
It is used a great deal in the Oil industry (and obviously aerospace
and nuclear engineering and optimisation in manufacturing.
Louis Krupp
<snip text from original, on-topic post>
>>> English-language-usage nitpick: "Starting to doubt fortran" will be
>>> read by many native speakers as "starting to think fortran is no good",
>>> which I think isn't what you mean. I notice that many non-native
>>> speakers use "doubt" in contexts in which I think most native speakers
>>> (in the US anyway) would use "question".
>
> [ snip ]
>
>> I'm not sure I'd say that Indians (who I've seen using "doubt" as a
>> synonym for "question") aren't native speakers. English might not be
>> their mother tongue (there are hundreds of languages there), but it's a
>> common language in India. People seem to learn English very early, only
>> with a slightly different vocabulary and verb preference than in Britain
>> or North America. I get the impression that Indians use English to
>> communicate with each other as much as with foreigners, and if they all
>> learn the same usage of "doubt," then the rest of us might as well get
>> used to it.
>
> Oh dear. What, it wasn't enough to have the US and the UK be "two
> countries separated by a common language"? we need more variants?
> Sort of a :-).
If you look closely, it's more complicated than that. The Irish have
ways of saying things in English that I presume came from the Irish
language ("It's after being summer" or "He'd drink taken"). None of
this, as far as I know, correlates with the speaker's fluency in Irish.
The UK itself has its share of variations. The people north of the
Border at least have a name for their dialect, or dialects, or language;
exactly how to classify "Scots" is a political question as much as
anything else.
I took a class from a Scotsman years ago. I wouldn't have accused him
of not speaking perfect English, and I'm pretty sure he wasn't lecturing
us in Broad Scots, but his accent alone assured that I didn't understand
much of what he said. But then I never was much of a student...
Oh, and in Canada, you wait in a lineup, something which has a
completely different meaning here in the States.
Louis
blm...@myrealbox.com
[ snip ]
> >> I'm not sure I'd say that Indians (who I've seen using "doubt" as a
> >> synonym for "question") aren't native speakers.
[ snip ]
> > Oh dear. What, it wasn't enough to have the US and the UK be "two
> > countries separated by a common language"? we need more variants?
> > Sort of a :-).
>
> If you look closely, it's more complicated than that. The Irish have
> ways of saying things in English that I presume came from the Irish
> language ("It's after being summer" or "He'd drink taken"). None of
> this, as far as I know, correlates with the speaker's fluency in Irish.
>
> The UK itself has its share of variations. The people north of the
> Border at least have a name for their dialect, or dialects, or language;
> exactly how to classify "Scots" is a political question as much as
> anything else.
It is, isn't it? (More complicated than UK versus US.)
> I took a class from a Scotsman years ago. I wouldn't have accused him
> of not speaking perfect English, and I'm pretty sure he wasn't lecturing
> us in Broad Scots, but his accent alone assured that I didn't understand
> much of what he said. But then I never was much of a student...
Yeah. I spent a month in New Zealand, a long time ago, and I
remember frequently not being able to parse what I heard people say
into English I could recognize. I wasn't especially good at foreign
("other foreign"?) languages either. Maybe that's related.
> Oh, and in Canada, you wait in a lineup, something which has a
> completely different meaning here in the States.
Another nice example of the "two countries divided" adage.
It's kind of interesting to me that I've asked about this usage
("doubt" where a US English speaker -- did I say it right this
time? :-) -- would say "question") in other newsgroups (e.g.,
alt.usage.english), and I think you're the first person to say that
it's common usage in Indian speakers of English. This probably
means I should stop trying to educate the non-natives and accept it
as regional variation.
Nom...@gmail.com
> In article <130f1ah96m9...@corp.supernews.com>,
Its funny to see how this was posting was supposed to be a question on
a computer language turned into a discussion on different variations
of English around the globe.
Gary Scott
blm...@myrealbox.com
Gary Scott <garyl...@sbcglobal.net> wrote:
> Nom...@gmail.com wrote:
[ snip ]
> > Its funny to see how this was posting was supposed to be a question on
> > a computer language turned into a discussion on different variations
> > of English around the globe.
> >
> It's more amazing how rare these off topic diversions are here.
>
I guess it is, isn't it? Thread drift is much more common in some of
the groups where I hang out, and that probably influenced my decision
to post something admittedly far off-topic for this group. My thinking
was that by changing the subject line and adding "OT" I wouldn't raise
any hackles. Tell me I'm wrong and I'll try to remember not to do it
again, though. It's just that "doubt" for "question" is a pet peeve
of mine -- though something I've learned from this discussion is that
maybe it shouldn't be.
I do kind of wonder how many other people looked at the subject line
and said "oh no, another flamefest ...." Maybe everyone else knows
Indian English better than I do!
e p chandler
> In article <qNPNh.75$5e...@newssvr11.news.prodigy.net>,
Using "doubt" for "question" is still a minor peeve with me. IMO there
are other more annoying things that I regard as breaches of
"netiquette":
[flame on]
1. posting without reading or doing a search of newsgroups.
Particularly a FAQ that has been answered both recently and
frequently. [Yes sometimes it is hard to do a good search without
knowing the right "term of art". :-).]
2. posting a request for help without supplying helpful details such
as compiler, operating system, computer hardware, etc.
3. posting a request for help without showing work already done,
particularly by students apparently looking for instant answers to
homework problems. [I'm perfectly willing to spend my own time going
over the programs of others given something to work with.]
4. posting a request for answers to common interview questions [not a
real problem in this newsgroup but present in others].
[flame off]
-- elliot
John Harper
blm...@myrealbox.com <blm...@myrealbox.com> wrote:
>
>English-language-usage nitpick: "Starting to doubt fortran" will be
>read by many native speakers as "starting to think fortran is no good",
>which I think isn't what you mean. I notice that many non-native
>speakers use "doubt" in contexts in which I think most native speakers
>(in the US anyway) would use "question".
This native speaker (admittedly from NZ) thinks that wouldn't avoid
the problem because "question" also has a negative connotation. The
subject line "Starting to question fortran" would make me think "Oh?
Has someone found a logical error in the Fortran standard?" (A few
days ago Bob Corbett did exactly that, showing how a variable can be
both defined and undefined at the same time.)
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
blm...@myrealbox.com
John Harper <har...@mcs.vuw.ac.nz> wrote:
> In article <56oburF...@mid.individual.net>,
> blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> >
> >English-language-usage nitpick: "Starting to doubt fortran" will be
> >read by many native speakers as "starting to think fortran is no good",
> >which I think isn't what you mean. I notice that many non-native
> >speakers use "doubt" in contexts in which I think most native speakers
> >(in the US anyway) would use "question".
>
> This native speaker (admittedly from NZ) thinks that wouldn't avoid
> the problem because "question" also has a negative connotation. The
> subject line "Starting to question fortran" would make me think "Oh?
> Has someone found a logical error in the Fortran standard?" (A few
> days ago Bob Corbett did exactly that, showing how a variable can be
> both defined and undefined at the same time.)
>
Very much agreed. I could have made it clearer that there are also
cases in which neither word works as intended. Sorry about that.
I did say, at the end of my original post:
Dmitry V. Gorbatovsky
> Hi
> I was wondering if its a good idea to start learning to program
> fortran and why?
I would insist to call both of this languages "Domain Specific".
One to deal with numericall algorithms and another to write a hardware
specific code.
> is it better or faster than C??
So it depends on problem in hand. For numerical code Fortran is definitely
better than any alternatives, without doubts. The code itself would be
simpler(clearer) so your performance as programmer would be higher with
less bugs. And all that without any performance penalty on run time
(execution).
> thanks
> Chris
If you doing numericall programming I may safely advice you to compile
Fortran routines as shared libraries and call it from "universal" high
level language. It is a very convenient and robust technique.
Regards,
Dmitry
Beliavsky
wrote:
> Noma...@gmail.com wrote:
> > Hi
> > I was wondering if its a good idea to start learning to program
> > fortran and why?
>
> I would insist to call both of this languages "Domain Specific".
I understand your view but don't agree with it, nor does the Wikipedia
http://en.wikipedia.org/wiki/Fortran http://en.wikipedia.org/wiki/General-purpose_programming_language
Fortran has been used since its inception not just to crunch numbers
but write compilers and interpreters, as discussed at
http://compilers.iecc.com/comparch/article/95-10-088 . The book
"Software Tools", written by Kernighan and Plauger in 1976, uses
Ratfor, which is converted automatically to Fortran 66, as their
programming language, explaining their decision as follows (p3)
"One of the problems with writing about programming is choosing a
language for the programs. No single language is known to all readers,
compilable on all machines, and easy to read. We must compromise:
since Fortran is widely available and well supported, we will use it
as our base in this book. Most programmers have at least a reading
knowledge of Fortran, and it runs on almost all computers. The
language is sufficiently well standardized that programs can be
written to run without change on a wide variety of systems. In a real
sense, Fortran is the lingua franca of computing, the closest thing
there is to a universal language."
As a Fortran partisan, I am not going to list their reasons for using
Ratfor rather than straight Fortran 66 :), but the features added in
Fortran 90 remove the need for a preprocessor such as Ratfor.
Ron Shepard
"Beliavsky" <beli...@aol.com> wrote:
> As a Fortran partisan, I am not going to list their reasons for using
> Ratfor rather than straight Fortran 66 :), but the features added in
> Fortran 90 remove the need for a preprocessor such as Ratfor.
It has been a while since I've read the book, but I remember
thinking in the early 80's that f77 would have been sufficient for
their code examples too. Did they use pointers, or structures, or
allocatable objects or anything that really does need f90 or later?
Btw, my ear thinks that "consider" is the best word to use instead
of "doubt" in this context.
$.02 -Ron Shepard
Charles Russell
> On Mar 26, 7:01 pm, "Dmitry V. Gorbatovsky" <dg-nos...@midasitech.com>
> wrote:
>
>>Noma...@gmail.com wrote:
>>
>>>Hi
>>>I was wondering if its a good idea to start learning to program
>>>fortran and why?
>>
>>I would insist to call both of this languages "Domain Specific".
>
>
> I understand your view but don't agree with it, nor does the Wikipedia
>
> http://en.wikipedia.org/wiki/Fortran http://en.wikipedia.org/wiki/General-purpose_programming_language
>
> Fortran has been used since its inception not just to crunch numbers
> but write compilers and interpreters, as discussed at
> http://compilers.iecc.com/comparch/article/95-10-088 . The book
> "Software Tools", written by Kernighan and Plauger in 1976, uses
> Ratfor, which is converted automatically to Fortran 66, as their
> programming language, explaining their decision as follows (p3)
They cheated. You can't actually run the code in the book without adding
some system calls that did not exist in fortran up through '77 and may
still not exist - can you write the equivalent of getc in current fortran?
Beliavsky
wrote:
> In article <1174972717.966481.291...@y66g2000hsf.googlegroups.com>,
>
> "Beliavsky" <beliav...@aol.com> wrote:
> > As a Fortran partisan, I am not going to list their reasons for using
> > Ratfor rather than straight Fortran 66 :), but the features added in
> > Fortran 90 remove the need for a preprocessor such as Ratfor.
>
> It has been a while since I've read the book, but I remember
> thinking in the early 80's that f77 would have been sufficient for
> their code examples too. Did they use pointers, or structures, or
> allocatable objects or anything that really does need f90 or later?
No, but Ratfor, unlike Fortran 77, has free source form and does not
required a numbered line to write a loop. ENDDO was a common extension
of F77 compilers.
Tim Prince
> In article <1174972717.9...@y66g2000hsf.googlegroups.com>,
> "Beliavsky" <beli...@aol.com> wrote:
>
>> As a Fortran partisan, I am not going to list their reasons for using
>> Ratfor rather than straight Fortran 66 :), but the features added in
>> Fortran 90 remove the need for a preprocessor such as Ratfor.
>
> It has been a while since I've read the book, but I remember
> thinking in the early 80's that f77 would have been sufficient for
> their code examples too. Did they use pointers, or structures, or
> allocatable objects or anything that really does need f90 or later?
CYCLE and EXIT avoid GOTOs with ugly labels in Fortran representation of
ratfor code, and are easy to implement. With the multi-level versions,
named loops are needed for clean representation.
The original ratfor, by definition, didn't "really need" f77, other than
to make the Fortran representation legible.
Ben Hetland
> Nom...@gmail.com wrote:
[...]
>> is it better or faster than C??
> So it depends on problem in hand.
Probably true, but ...
> For numerical code Fortran is definitely
> better than any alternatives, without doubts. The code itself would be
> simpler(clearer) so your performance as programmer would be higher with
> less bugs.
How can you claim this?
I just see too many contradictions to such a claim:
1. For "numerical code" the difference between C and Fortran is only
minor. (In fact C borrowed a lot of its formula syntax from just
Fortran...) That favors neither of the two significantly.
2. Whether or not the code is simple or clear depends partly on how
familiar the reader is with the syntax/language at hand, partly on the
skills of the code's author. It is possible to write virtually
unreadable code in both languages. Traditional Fortran code using only
capitals can be argued to be less readable, but that argument isn't
relevant these days when modern compilers accept lower case just the
same. So no specific advantage to any party here either.
3. When judging the degree of freedom the author has for producing code
with good readability, Fortran has the disadvantage of rigid and
odd/archaic line formatting rules (in fixed format), and imposes limits
on line lengths (72 or 132), both of which enforce limitations in the
freedom the author has to arrange his/her formulas with a readable
layout in mind. (66 character positions to play with is really not
much!) C does not have this limitation, but on the other hand too long
lines don't behave very well when printed for instance. I.e., I'd say
this isn't so much a relevant issue to favor one over the other in
practical life.
4. In Fortran it's often necessary to use more temporary variables to
store intermediate sub-expressions, or even literal numeric values (ever
used IONE or IZERO anyone?). This generally requires more lines of code
for expressing the same calculation in Fortran than in C. On the other
hand Fortran offers some convenient shorthands for implicit looping
(implied DO and index ranges, for instance) that need to be written more
explicitly in C (principle: "what you see is all you get", so "you have
to code everything you want to do"). So I find it hard to conclude one
way or the other which is "best" here, and it can also be a matter of
personal preference.
5. Regarding this:
> And all that without any performance penalty on run time
> (execution).
That is in fact not always the truth. In both of these languages it is
an important principle that "you don't pay for what you don't use", but
in real life things aren't always that ideal. Since the claim quoted
above was about numerical code, I think the common feature of run-time
checking of array indices[1] can serve as a good example. You don't pay
this price in C, but then again you are allowed to shoot yourself in the
foot if you like, and bugs in the code causing for instance indexing
errors unfortunately tend to magically intrude into code of either
language. Stricter rules regarding aliasing can give a Fortran optimizer
an advantage with arrays for instance, but there might also be an
advantage in the almost complete freedom (flexibility) given to the C
programmer dealing in the pointer/array minefield.
And I can probably make a long list of such arguments, but I think I'll
stop here ... An assumption is of course that we either compare a good
Fortran programmer with a good C programmer, or a bad with a bad one.
One writes best code in a language that one is familiar with, and
comparing Fortran code from a good Fortran coder with C code from a bad
C coder just isn't relevant IMHO. Or vice versa.
Bottom line: When programming/coding, one really has to know one's
programming language no matter which one is chosen. Regarding the
readability (or immediate understanding) of the finished code for other
people not familiar with the language, see my points 1 and 2 above.
So, if you know Fortran but not C, your best off if you do your work in
Fortran. If you know C but not Fortran, then choose C. If you know both
very well, you're either lucky in the case you're starting something new
and can choose which one best fits the problem. Or, you're unlucky if
you're assigned the task of maintaining some other fellow's code.
[1] Yes, I know one often can turn this off with many compilers, but in
real life one doesn't always dare that.
--
-+-Ben-+-
highegg
> Dmitry V. Gorbatovsky wrote:
> > Noma...@gmail.com wrote:
> [...]
> >> is it better or faster than C??
> > So it depends on problem in hand.
>
> Probably true, but ...
>
> > For numerical code Fortran is definitely
> > better than any alternatives, without doubts. The code itself would be
> > simpler(clearer) so your performance as programmer would be higher with
> > less bugs.
>
I would probably also disagree, because I consider it to bold a
statement.
> How can you claim this?
> I just see too many contradictions to such a claim:
>
> 1. For "numerical code" the difference between C and Fortran is only
> minor. (In fact C borrowed a lot of its formula syntax from just
> Fortran...) That favors neither of the two significantly.
Given only scalar expressions, that's true. Perhaps the exponentiation
operator is a point for Fortran.
> 2. Whether or not the code is simple or clear depends partly on how
> familiar the reader is with the syntax/language at hand, partly on the
> skills of the code's author. It is possible to write virtually
> unreadable code in both languages. Traditional Fortran code using only
> capitals can be argued to be less readable, but that argument isn't
> relevant these days when modern compilers accept lower case just the
> same. So no specific advantage to any party here either.
It could be just my opinion (although definitely shared by plenty of
people) that most Fortran constructs is somewhat easier to read - IF-
END IF,DO-END DO vs C's {} for everything. OTOH, C is easier to write
by the same argument :)
> 3. When judging the degree of freedom the author has for producing code
> with good readability, Fortran has the disadvantage of rigid and
> odd/archaic line formatting rules (in fixed format), and imposes limits
> on line lengths (72 or 132), both of which enforce limitations in the
> freedom the author has to arrange his/her formulas with a readable
> layout in mind. (66 character positions to play with is really not
> much!) C does not have this limitation, but on the other hand too long
> lines don't behave very well when printed for instance. I.e., I'd say
> this isn't so much a relevant issue to favor one over the other in
> practical life.
Fixed format is obsolete. I agree that the line length limitation can
sometimes cause trouble. OTOH, I was never sure with the semicolons in
C.
> 4. In Fortran it's often necessary to use more temporary variables to
> store intermediate sub-expressions, or even literal numeric values (ever
> used IONE or IZERO anyone?). This generally requires more lines of code
> for expressing the same calculation in Fortran than in C.
I don't think so. Fortran's array-valued functions, vector indexing
etc. usually let you omit a temporary that you would need with C.
Also, intrinsics like HUGE() usually need to be replaced by predefined
constants in C.
In C, you can sometimes spare a local variable by reusing a function
argument. (is in F2003) Others, however, consider this a bad practice.
Dunno what IZERO or IONE is.
> 5. Regarding this:> And all that without any performance penalty on run time
> > (execution).
>
> That is in fact not always the truth. In both of these languages it is
> an important principle that "you don't pay for what you don't use", but
> in real life things aren't always that ideal. Since the claim quoted
> above was about numerical code, I think the common feature of run-time
> checking of array indices[1] can serve as a good example.
Dunno what you have on mind. Fortran does not mandate bounds checking.
No compiler I'm aware of has array bounds checking turned on by
default.
> You don't pay
> this price in C, but then again you are allowed to shoot yourself in the
> foot if you like, and bugs in the code causing for instance indexing
> errors unfortunately tend to magically intrude into code of either
> language.
> Stricter rules regarding aliasing can give a Fortran optimizer
> an advantage with arrays for instance, but there might also be an
> advantage in the almost complete freedom (flexibility) given to the C
> programmer dealing in the pointer/array minefield.
True; moreover, much of aliasing problems are addressed by C99's
strict pointers. I think it's particularly pointers what makes C so
powerful.
I think that it is practical for numerics to know both C and Fortran
at least a little, as one will certainly meet code in both.
I decided to go with Fortran particularly because of its array
facilities and the fact that it claims to be numerically targeted -
thus, chances are that it will incorporate important numerical
features more easily in the future.
Gordon Sande
> Dmitry V. Gorbatovsky wrote:
>> Nom...@gmail.com wrote:
> [...]
>>> is it better or faster than C??
>> So it depends on problem in hand.
>
> Probably true, but ...
>
>
>> For numerical code Fortran is definitely
>> better than any alternatives, without doubts. The code itself would be
>> simpler(clearer) so your performance as programmer would be higher with
>> less bugs.
>
> How can you claim this?
> I just see too many contradictions to such a claim:
>
> 1. For "numerical code" the difference between C and Fortran is only
> minor. (In fact C borrowed a lot of its formula syntax from just
> Fortran...) That favors neither of the two significantly.
>
> 2. Whether or not the code is simple or clear depends partly on how
> familiar the reader is with the syntax/language at hand, partly on the
> skills of the code's author. It is possible to write virtually
> unreadable code in both languages. Traditional Fortran code using only
> capitals can be argued to be less readable, but that argument isn't
> relevant these days when modern compilers accept lower case just the
> same. So no specific advantage to any party here either.
The distinction between local variables and arguements in C that is
evident by the need to know which are pointers or not is not conducive
to readability. The peppering of code with the dereferncing '*"s is
not a good thing. Fortran got it better with pointer operations
requiring their own operators. Fortran pointers have a much richer
sematics so comparisons with C pointers are dificult for other reasons.
> 3. When judging the degree of freedom the author has for producing code
> with good readability, Fortran has the disadvantage of rigid and
> odd/archaic line formatting rules (in fixed format), and imposes limits
> on line lengths (72 or 132), both of which enforce limitations in the
> freedom the author has to arrange his/her formulas with a readable
> layout in mind. (66 character positions to play with is really not
> much!) C does not have this limitation, but on the other hand too long
> lines don't behave very well when printed for instance. I.e., I'd say
> this isn't so much a relevant issue to favor one over the other in
> practical life.
Fixed format went out with all caps. But then how much 40 year legacy
code still works in C?
> 4. In Fortran it's often necessary to use more temporary variables to
> store intermediate sub-expressions, or even literal numeric values (ever
> used IONE or IZERO anyone?). This generally requires more lines of code
> for expressing the same calculation in Fortran than in C. On the other
> hand Fortran offers some convenient shorthands for implicit looping
> (implied DO and index ranges, for instance) that need to be written more
> explicitly in C (principle: "what you see is all you get", so "you have
> to code everything you want to do"). So I find it hard to conclude one
> way or the other which is "best" here, and it can also be a matter of
> personal preference.
Most folks consider the ability to grab the internals out of C expressions
with embedded assignments as a prime example of a write only language
for hackers. The collection of += type symbols have no equivalent in
conventional mathematical notation so need explanation as to their
semantics, particularly with && and such. Programming is an area where
clever is often a rather bad thing and you seem to be like a lot of
features that encourage cleverness at its worst.
> 5. Regarding this:
>> And all that without any performance penalty on run time
>> (execution).
> That is in fact not always the truth. In both of these languages it is
> an important principle that "you don't pay for what you don't use", but
> in real life things aren't always that ideal. Since the claim quoted
> above was about numerical code, I think the common feature of run-time
> checking of array indices[1] can serve as a good example. You don't pay
> this price in C, but then again you are allowed to shoot yourself in the
> foot if you like, and bugs in the code causing for instance indexing
> errors unfortunately tend to magically intrude into code of either
> language. Stricter rules regarding aliasing can give a Fortran optimizer
> an advantage with arrays for instance, but there might also be an
> advantage in the almost complete freedom (flexibility) given to the C
> programmer dealing in the pointer/array minefield.
Subscript checking is a common runtime option in Fortran. Less commonly
supported in C where it is more needed because of the C storeage allocation
idioms. Once past debugging the option is turned off. During debugging
is is a great help. The default is option off. It is clear that more
folks should use it judging from the questions that keep coming up.
Curious feature of C that it allows more, better and bigger errors!
Most would view that as hardly a worthwhile feature.
> And I can probably make a long list of such arguments, but I think I'll
> stop here ... An assumption is of course that we either compare a good
> Fortran programmer with a good C programmer, or a bad with a bad one.
> One writes best code in a language that one is familiar with, and
> comparing Fortran code from a good Fortran coder with C code from a bad
> C coder just isn't relevant IMHO. Or vice versa.
>
> Bottom line: When programming/coding, one really has to know one's
> programming language no matter which one is chosen. Regarding the
> readability (or immediate understanding) of the finished code for other
> people not familiar with the language, see my points 1 and 2 above.
>
> So, if you know Fortran but not C, your best off if you do your work in
> Fortran. If you know C but not Fortran, then choose C. If you know both
> very well, you're either lucky in the case you're starting something new
> and can choose which one best fits the problem. Or, you're unlucky if
> you're assigned the task of maintaining some other fellow's code.
>
>
> [1] Yes, I know one often can turn this off with many compilers, but in
> real life one doesn't always dare that.
Are you seriously suggesting that running with wild subscripts is a thing
to be tolerated in a "working" program?
blm...@myrealbox.com
Ron Shepard <ron-s...@NOSPAM.comcast.net> wrote:
[ snip ]
> Btw, my ear thinks that "consider" is the best word to use instead
> of "doubt" in this context.
As the person who raised this point in the first place, I'll agree.
blm...@myrealbox.com
Ben Hetland <ben.a....@sintef.no> wrote:
> Dmitry V. Gorbatovsky wrote:
> > Nom...@gmail.com wrote:
> [...]
> >> is it better or faster than C??
> > So it depends on problem in hand.
>
> Probably true, but ...
>
>
> > For numerical code Fortran is definitely
> > better than any alternatives, without doubts. The code itself would be
> > simpler(clearer) so your performance as programmer would be higher with
> > less bugs.
>
> How can you claim this?
> I just see too many contradictions to such a claim:
And right about here this subthread starts to drift in the
direction of what the subject line suggests to (some of?) us US
English speakers ....
OT, but a :-) maybe.
[ snip ]
Craig Powers
>
> 3. When judging the degree of freedom the author has for producing code
> with good readability, Fortran has the disadvantage of rigid and
> odd/archaic line formatting rules (in fixed format), and imposes limits
> on line lengths (72 or 132), both of which enforce limitations in the
> freedom the author has to arrange his/her formulas with a readable
> layout in mind. (66 character positions to play with is really not
> much!) C does not have this limitation, but on the other hand too long
> lines don't behave very well when printed for instance. I.e., I'd say
> this isn't so much a relevant issue to favor one over the other in
> practical life.
As a practical matter, I find even 132 to be longer than I need. My
emacs is set to wrap my lines at ca. 100 characters (which can be done
easily with continuations). I'm sure YMMV.
Ben Hetland
>> 4. In Fortran it's often necessary to use more temporary variables to
>> store intermediate sub-expressions, or even literal numeric values (ever
>> used IONE or IZERO anyone?). This generally requires more lines of code
>> for expressing the same calculation in Fortran than in C.
>
> I don't think so. Fortran's array-valued functions, vector indexing
> etc. usually let you omit a temporary that you would need with C.
Yes, those are powerful indeed! And it sure is convenient to have them
as standard, as opposed to requiring similar capabilities delivered by a
library in C (which isn't "standard" or included).
Regarding readability for a reader unfamiliar with Fortran's specific
semantics here, I think it can sometimes be just as cryptic as it can
help clarify. It probably depends on use/misuse by the programmer. For
instance, when seeing something like
c(1+i:n)
should I interpret it as the element at index (1+(i/n)) in the array
named 'c'? Or perhaps even as the result of the expression (c*(1+(i/n)))
since that is the closest interpretation of a similar sequence of
mathematical symbols?
> Also, intrinsics like HUGE() usually need to be replaced by predefined
> constants in C.
But that offers little practical advantage over writing DBL_MAX or
INT_MAX in C, does it? That is just as standard in C as HUGE() is in
Fortran90.
BTW, for the enjoyment of it I once experimented with a thing like
#define oo DBL_MAX
which perhaps was useful as it resembles the infinity sign, which
conceptually could contribute to enhancing readability when writing
things like
minval = oo;
for(i=0; i<maxi; ++i)
minval = min(v[i],minval);
--
-+-Ben-+-
Ben Hetland
> The distinction between local variables and arguements in C that is
> evident by the need to know which are pointers or not is not conducive
> to readability. The peppering of code with the dereferncing '*"s is
> not a good thing.
Yes, this is true. But using that kind of notation is not the most
necessary thing in code dealing with "numerical programming" that was
the context here. The * operator is easy to confuse with a
multiplication if the context is calculation of a lot of mathematical
formulas. Reading lines like
*p++ = pow(x,2.5)* **z-- / exp(s->x) + a[i]
isn't much fun (let alone without the spaces!), but one isn't required
to use every available C feature in undesirable places either. That is,
unless perhaps one is trying to win a prize in an "obfuscated C contest"
or something. ;-)
> Fortran got it better with pointer operations
> requiring their own operators. Fortran pointers have a much richer
> sematics so comparisons with C pointers are dificult for other reasons.
C pointers are definitely a difficult area, and the syntax probably
makes it harder to learn the concept they realize, a concept which is
hard enough to grasp by itself. Past experience with beginners in C
coding probably will confirm that.
Fortran pointers and their concepts aren't exactly intuitive either,
IMHO, but I'm still sometimes confused with their semantics so I'm biased.
Pascal pointers realized a concept that I personally found much more
intuitive to grasp, as their syntax is fairly consistent with what they
point at. YMMV
> Fixed format went out with all caps.
Unfortunately not if you modify part of a larger, legacy source file,
and if you also have to cooperate with people that still aren't updated
in "their" language since 1980 or so... I don't think it is so relevant
for discussing pro/con mentioned claim, though.
> But then how much 40 year legacy code still works in C?
Exactly nothing I presume, since C didn't exist in 1967...
This is also not relevant when choosing a language to produce new
numeric code with.
And if you want to prove a point here, then show me a piece of 40 year
old legacy Fortran code that does something useful and still compiles
with a modern, strict Fortran95 compiler.
> Most folks consider the ability to grab the internals out of C expressions
> with embedded assignments as a prime example of a write only language
> for hackers. The collection of += type symbols have no equivalent in
> conventional mathematical notation so need explanation as to their
> semantics, particularly with && and such.
Well, those kind of things were not exactly my point, either. I was
thinking more along the lines of
foo(1.0, c[i], b, a);
printf("%d %f %f\n", (a->i+42), b, 2.0*bar(b,a->f));
which in Fortran is more likely to have to be written as
ione = 1.0
call foo(ione, c(i), b, a)
f = a%f
r = 2.0*bar(b,f)
n = a%i + 42
write(*,*) n, b, r
(Assuming more thoughtful planning of the Fortran code, I assume it can
be improved on, but the tendency of this effect is still present.)
> Programming is an area where
> clever is often a rather bad thing and you seem to be like a lot of
> features that encourage cleverness at its worst.
No, I hope I am not a lot of such features or like those. ;-)
> Curious feature of C that it allows more, better and bigger errors!
> Most would view that as hardly a worthwhile feature.
Well, sometimes dynamite can be useful even though it can kill people.
>> [1] Yes, I know one often can turn this off with many compilers, but in
>> real life one doesn't always dare that.
>
> Are you seriously suggesting that running with wild subscripts is a thing
> to be tolerated in a "working" program?
Not at all!
At least not if being "wild" suggests that the program has no control of
their USE. But in other cases, a "wild subscript" can actually be a
derivation of some input that the program does not fully control, and
all possible permutations of input isn't always practically testable.
But then again we're probably far beyond the typical case of solving
numerical problems, aren't we?
--
-+-Ben-+-
Gordon Sande
> highegg wrote:
>>> 4. In Fortran it's often necessary to use more temporary variables to
>>> store intermediate sub-expressions, or even literal numeric values (ever
>>> used IONE or IZERO anyone?). This generally requires more lines of code
>>> for expressing the same calculation in Fortran than in C.
>>
>> I don't think so. Fortran's array-valued functions, vector indexing
>> etc. usually let you omit a temporary that you would need with C.
>
> Yes, those are powerful indeed! And it sure is convenient to have them
> as standard, as opposed to requiring similar capabilities delivered by a
> library in C (which isn't "standard" or included).
>
> Regarding readability for a reader unfamiliar with Fortran's specific
> semantics here, I think it can sometimes be just as cryptic as it can
> help clarify. It probably depends on use/misuse by the programmer. For
> instance, when seeing something like
> c(1+i:n)
>
> should I interpret it as the element at index (1+(i/n)) in the array
> named 'c'? Or perhaps even as the result of the expression (c*(1+(i/n)))
> since that is the closest interpretation of a similar sequence of
> mathematical symbols?
I could believe that it just might possibly be read like
c(1+i;n)
where c(1+i) has a parameter n so one can only believe that either you
making it up as you go or have little exposure to mathematics
"as she is spoke". Much more likely is to read it as
c(1+i, ..., n)
which is what it is. There are loads of books that would lead to that.
Charles Russell
>
> And if you want to prove a point here, then show me a piece of 40 year
> old legacy Fortran code that does something useful and still compiles
> with a modern, strict Fortran95 compiler.
Without checking the exact dates, things like NL2SOL, MINPACK, the
Forsythe, Moler, and Moler routines, QUADPACK, FFTPACK, ODEPACK, the
PORT optimization package, Powell's PRAXIS, etc, etc, must be at least
30 years old. If a "modern, strict Fortran95 compiler" will not compile
them, then that compiler is useless to me.
Charles Russell
Powell's PRAXIS
correction: Brent's PRAXIS
Richard Maine
> Ben Hetland wrote:
>
> > And if you want to prove a point here, then show me a piece of 40 year
> > old legacy Fortran code that does something useful and still compiles
> > with a modern, strict Fortran95 compiler.
>
> Without checking the exact dates, things like NL2SOL, MINPACK, the
> Forsythe, Moler, and Moler routines, QUADPACK, FFTPACK, ODEPACK, the
> PORT optimization package, Powell's PRAXIS, etc, etc, must be at least
> 30 years old.
If 30 years is ok, I've got some of my own codes that would fit the
bill. I don't use those codes any more, as I've done better since, but
the old codes still work. 40 years I can't do though.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Jan Vorbrüggen
> thinking more along the lines of
>
> foo(1.0, c[i], b, a);
> printf("%d %f %f\n", (a->i+42), b, 2.0*bar(b,a->f));
>
> which in Fortran is more likely to have to be written as
>
> ione = 1.0
> call foo(ione, c(i), b, a)
> f = a%f
> r = 2.0*bar(b,f)
> n = a%i + 42
> write(*,*) n, b, r
Why in hell would anybody write it that way!? Since at least F77, you can
write this in two lines exactly like in C! And it's even easier in Fortran,
because printf doesn't have the equivalent of a * format.
Jan
glen herrmannsfeldt
Ben Hetland wrote:
> And if you want to prove a point here, then show me a piece of 40 year
> old legacy Fortran code that does something useful and still compiles
> with a modern, strict Fortran95 compiler.
Do you allow replacing (1) with (*) in array dimensions?
So much old code was done that way that it won't compile
in new compilers, but otherwise will work.
-- glen
glen herrmannsfeldt
(snip)
> Given only scalar expressions, that's true. Perhaps the
> exponentiation operator is a point for Fortran.
Well, not only the operator, but that it allows one to
express integer powers directly.
(snip)
> I don't think so. Fortran's array-valued functions, vector indexing
> etc. usually let you omit a temporary that you would need with C.
Well, it might be that a temporary array is generated by
the compiler instead. On average I would say it is about
equal.
(snip)
>>That is in fact not always the truth. In both of these languages it is
>>an important principle that "you don't pay for what you don't use", but
>>in real life things aren't always that ideal. Since the claim quoted
>>above was about numerical code, I think the common feature of run-time
>>checking of array indices[1] can serve as a good example.
In most C implementations it is not possible to do bounds checking
on pointers. That isn't required by the standard, but it is usual.
> Dunno what you have on mind. Fortran does not mandate bounds checking.
> No compiler I'm aware of has array bounds checking turned on by
> default.
WATFIV does, and I don't believe it can even be turned off.
-- glen
Ben Hetland
> Why in hell would anybody write it that way!?
I can only guess, but I think it's because they've been bit by some
strange effect if they didn't some time in the past.
Others might do it because all other code they work with has been done
that way, and their knowledge of the exact, defined behavior according
to any standard is really lacking.
I used to be in that latter category myself, learning Fortran only
through working with "experienced" Fortran coders. I'm still partly
there, I think, but I do have an interest in the standard and all its
intricacies, which I hope will gradually enable me to produce "better"
code. (I wouldn't care to hang around in this ng otherwise...) As I go
along though, it just too often strikes me how amazingly incorrect those
"old fortranners" were in what they have thought me over the years. That
is, "incorrect" in the sense of not being standard compliant or actually
being outside the scope of that the standard covers. But probably true
facts for any real life's compiler's specific implementation of the
time. For me, that means I have to do some re-learning from time to
time. I can think of better ways to spend my working hours. :-(
> Since at least F77, you can write this in two lines exactly like
> in C! And it's even easier in Fortran, because printf doesn't have
> the equivalent of a * format.
That's really good to read! Another brief re-learning for me then,
because I just remember vaguely something about expressions not being
allowed inside write statements.
--
-+-Ben-+-
Gordon Sande
Actually it still works. Just do not tempt fate by turning on subscript
checking unless the vendor has special cased a limit of 1 on arguements.
It is no longer considered good syle so you modification is recommended
but it is nor required.
Gordon Sande
> Charles Russell <NOS...@bellsouth.net> wrote:
>
>> Ben Hetland wrote:
>>
>>> And if you want to prove a point here, then show me a piece of 40 year
>>> old legacy Fortran code that does something useful and still compiles
>>> with a modern, strict Fortran95 compiler.
>>
>> Without checking the exact dates, things like NL2SOL, MINPACK, the
>> Forsythe, Moler, and Moler routines, QUADPACK, FFTPACK, ODEPACK, the
>> PORT optimization package, Powell's PRAXIS, etc, etc, must be at least
>> 30 years old.
>
> If 30 years is ok, I've got some of my own codes that would fit the
> bill. I don't use those codes any more, as I've done better since, but
> the old codes still work. 40 years I can't do though.
Some FFT codes that I wrote in 1966 are still in use in standard
X-ray crystallography packages if I believe my chemist friends.
That makes 41 years.
Ben Hetland
> Some FFT codes that I wrote in 1966 are still in use in standard
> X-ray crystallography packages if I believe my chemist friends.
> That makes 41 years.
And that is to be interpreted as _unchanged_ source for these 41 years?
If so, that is much better than my practical experience with Fortran,
where a lot of it won't compile if one changes compiler under the same
platform after perhaps only 1 year!
It probably also is an indication that the code I have got (from various
sources over the years) wasn't compliant to any standard, but then the
bulk of my concerns and experience is probably more related to file I/O
and crossing the C-Fortran language barrier than anything else, although
some of the code has definitely been in the "numerical" category too. It
should probably be mentioned that particularly some of these (to me
important) aspects haven't really been part of any standard until
perhaps someday a f2003 compiler becomes available.
--
-+-Ben-+-
Charles Russell
the
> bulk of my concerns and experience is probably more related to file I/O
> and crossing the C-Fortran language barrier than anything else, although
> some of the code has definitely been in the "numerical" category too
Fortran tradition is to leave the user interface as an exercise for the
user. What's left is extremely portable.
Beliavsky
> Gordon Sande wrote:
> > Some FFT codes that I wrote in 1966 are still in use in standard
> > X-ray crystallography packages if I believe my chemist friends.
> > That makes 41 years.
>
> And that is to be interpreted as _unchanged_ source for these 41 years?
The Crystallography Source Code Museum http://sdpd.univ-lemans.fr/museum/
has Fortran codes dating from 1965 to 2001. The patmat-67 code, which
starts
PROGRAM TRACER II
C
C DESCRIPTION. LATTICE TRANSFORMATION - CELL REDUCTION PROGRAM
C AUTHOR,DATE. S. L. LAWTON (APRIL 1967)
C LANGUAGE. FORTRAN IV FOR IBM 7040
can be compiled with the default options using Intel, g95, gfortran,
and Salford/Silverfrost but not Lahey/Fujitsu. I have not investigated
the running of the program.
Gordon Sande
> Gordon Sande wrote:
>> Some FFT codes that I wrote in 1966 are still in use in standard
>> X-ray crystallography packages if I believe my chemist friends.
>> That makes 41 years.
>
> And that is to be interpreted as _unchanged_ source for these 41 years?
Yes. Interestingly the code was writen as an exercise in exposition
with efficiency as a secondary objective. The resulting style meant
that there were absolutely no "clever" tricks. The efficiency turned
out to be first rate as well. Some codes that pay attention to small
cache sizes have come in and out of fashion over time. Caches were not
an issue in 1966 and the typical machine used by crystallographers is
not throttled by small caches, although that may be changing.
> If so, that is much better than my practical experience with Fortran,
> where a lot of it won't compile if one changes compiler under the same
> platform after perhaps only 1 year!
The story I have heard repeatedly is that C needs to be "updated" every
time a new version of the vendors C compiler comes out. I have always
understood that to be overly "clever" code although some claim that C
encourages such behaviour.
> It probably also is an indication that the code I have got (from various
> sources over the years) wasn't compliant to any standard, but then the
> bulk of my concerns and experience is probably more related to file I/O
> and crossing the C-Fortran language barrier than anything else, although
> some of the code has definitely been in the "numerical" category too. It
> should probably be mentioned that particularly some of these (to me
> important) aspects haven't really been part of any standard until
> perhaps someday a f2003 compiler becomes available.
Language interfacing tells you more about the assembly level conventions
of the compiler vendors than about either language. It is an exercise in
the worst forms of cleverness. (Some would claim it causes brain damage!)
Richard Maine
> Jan Vorbrüggen wrote:
> > Since at least F77, you can write this in two lines
>
> That's really good to read! Another brief re-learning for me then,
> because I just remember vaguely something about expressions not being
> allowed inside write statements.
You are probably remembering things about f66 or earlier. There were
lots of limitations like that in f66. As Jan noted, they changed in f77,
which was abouyt 30 years ago by now. Yes, I used to know people who
never really learned the "newfangled" f77 stuff. This included some
people who never actualy programmed with f66 compilers, but who learned
from those who did.
Another possibility is that you might be thinking about restrictions
frelating to recursive I/O. That does place some limits on the
expressions you can use. On occasion, the limits are annoying, but they
are pretty narrow. If you thik they restrict against expressions in
general, then you are either thinking about the old 66 issue or are
severely overgeneralizing this newer one. F2003 finally allows recursive
I/O for the most-requested cases.
Ben Hetland
> Yes. Interestingly the code was writen as an exercise in exposition
> with efficiency as a secondary objective. The resulting style meant
> that there were absolutely no "clever" tricks. The efficiency turned
> out to be first rate as well. Some codes that pay attention to small
> cache sizes have come in and out of fashion over time. Caches were not
> an issue in 1966 and the typical machine used by crystallographers is
> not throttled by small caches, although that may be changing.
Actually I'm much more impressed by what people were able to get out of
their computers at that time, or even in the 80's, than I am with what
is achieved with current hardware/software combinations, and that can
only be the software writers to blame.
> The story I have heard repeatedly is that C needs to be "updated" every
> time a new version of the vendors C compiler comes out. I have always
> understood that to be overly "clever" code although some claim that C
> encourages such behaviour.
Actually that specific language happens to be a central part of my
experience in that particular area. In pre-standard C days, the story
was partly true, but mostly it was about finding out which header files
to include on the "new" platform. That tended to reflect how the vendor
organized these files. The C code itself was mostly acceptable to the
compiler though, in fact much more than when feeding the same piece of
Fortran code to two different compilers.
These issues were best solved by just expanding on the customary section
of #include's at the top of each C file, controlling the selections
using #ifdef's. Since the C preprosessor _is_ in fact a central part of
the C language standard (as opposed to using a preprocessor with
Fortran), it could be reliably depended upon in a portable way. (The
"updated" code would still compile on the previus platform(s) it had
been adapted.) In post-standardization days much of this has gone away,
I think.
But then there are some specific issues, firstly the habit programmers
have of making assumptions about things that they shouldn't, like the
size of the 'int' type for instance. Bugs related to this I remember
were quite common at the time when many computers and compilers
transitioned from the 8/16-bit world into the 32-bit world. This is not
really a language issue, but more a coding issue. In theory the same
issues are inherent with Fortran too, but probably C was the candidate
most likely to come across it as it usually is preferred over Fortran
when doing things on a low level close to the metal. ;-)
Most vendors also extend the set of libraries to provide lower-level
access to the system. That's beyond the standard, but many tend to be so
consistent that they could be thought of as a de facto standard (the
functions open/close as opposed to the standardized fopen/close for
example). But at this level one can also come across anoying differences.
--
-+-Ben-+-
glen herrmannsfeldt
(I wrote)
>> Do you allow replacing (1) with (*) in array dimensions?
(snip)
> Actually it still works. Just do not tempt fate by turning on subscript
> checking unless the vendor has special cased a limit of 1 on arguements.
> It is no longer considered good syle so you modification is recommended
> but it is nor required.
Some compilers will do compile time subscript checking even with
run time checking turned off. I ran into that one not so long ago.
The OP said something like strict Fortran 95 so I figured it
wouldn't allow that.
-- glen
Gordon Sande
I have only ever seen compile time subscript checking for literal constant
subscripts. I suppose one might have literal subscripts into the begining
of a variable sized array. In the case at hand all subscripts would have
been by variables.
glen herrmannsfeldt
(snip)
> I have only ever seen compile time subscript checking for literal constant
> subscripts. I suppose one might have literal subscripts into the begining
> of a variable sized array. In the case at hand all subscripts would have
> been by variables.
Yes, the program I had used some literal (constant) subscripts.
Enough that the easiest solution was to go through and change
the appropriate 1 to *.
-- glen
Charles Russell
It is sure handy to have a compiler option to manage this (like g77's
-f-ugly-assumed)if you use much public-domain code.
Richard Maine
> On 2007-03-30 15:38:24 -0300, glen herrmannsfeldt <g...@ugcs.caltech.edu> said:
>
> > Gordon Sande wrote:
> > Some compilers will do compile time subscript checking even with
> > run time checking turned off. I ran into that one not so long ago.
> > The OP said something like strict Fortran 95 so I figured it
> > wouldn't allow that.
>
> I have only ever seen compile time subscript checking for literal constant
> subscripts. I suppose one might have literal subscripts into the begining
> of a variable sized array. In the case at hand all subscripts would have
> been by variables.
Yes, I've seen such subscript checking for literal constant subscripts.
And I've seen some widely-used code that got bit by it. I'm thinking it
might have been fftpack, though I won't absolutely swear by that.
Something like the algorithm startup being seeded with values from index
positions 1 and 2; the 2 failed compilation. Whatever it was, I
distinctly recall that teh compiler didn't even have an option to
disable that check. I had to fix the code (by changing the 1 to a *).
Pierre Asselin
> The story I have heard repeatedly is that C needs to be "updated" every
> time a new version of the vendors C compiler comes out. I have always
> understood that to be overly "clever" code although some claim that C
> encourages such behaviour.
Gordon, I don't know where you get your information. This hasn't been
my experience at all. Nor with Fortran, for that matter.
--
pa at panix dot com
robert....@sun.com
> Another possibility is that you might be thinking about restrictions
> frelating to recursive I/O. That does place some limits on the
> expressions you can use. On occasion, the limits are annoying, but they
> are pretty narrow. If you thik they restrict against expressions in
> general, then you are either thinking about the old 66 issue or are
> severely overgeneralizing this newer one. F2003 finally allows recursive
> I/O for the most-requested cases.
You must know different requestors from those with whom I have
had to deal. Sun f90/f95 has allowed recursive I/O to different
I/O units since 1998. However, our first implementation of
recursive I/O, which gave an error for doing recursive I/O to
the same I/O unit, generated lots of complaints from users.
The problem caused the complaints was that a program would
start writing to standard output, call a function that
detected an error, and try to write to write an error
message to standard output. Before Sun f90/f95 began
checking for recursive I/O, such a program would usually
work, especially if the program STOPped after writing the
error message. With the check for recursive I/O, the program
would not write the error message. If no IOSTAT= or ERR=
specifier was present, the program would terminate with an
error message about reentrant I/O.
Sun f90/f95 now gives an error for reentrant I/O after I/O
resumes on a write statement whose output list caused
recursive I/O. In the case described above, no error
condition is detected if the program terminates instead of
returning from the routine in which recursive I/O was done.
Bob Corbett
Richard Maine
> On Mar 30, 9:23 am, nos...@see.signature (Richard Maine) wrote:
>
> > F2003 finally allows recursive
> > I/O for the most-requested cases.
>
> You must know different requestors from those with whom I have
> had to deal.
Apparently. There is some real grounds for believing that. In
particular, the ones who you had to deal with were presumably the ones
who weren't happy with what you already had. I'd be rather surprised if
you got a lot of people asking for a feature that you already had. That
doesn't mean it isn't the most requested case; it just means that you
get a biased sample. Perhaps if you didn't support recursive I/O at all,
you'd have a broader sample of the requests.
Indeed, I recall having used Sun Fortran 77 in days when it did not
support recursive I/O at all. I recall helping quite a few people work
around that. I also had to code around it in my own code, but I at least
knew about the problem ahead of time instead of having to debug the
strange run-time symptoms. (Some compilers generated an understandabel
error message, but in others it just caused strange symptoms like
segfaults; I forget which way the early Sun f77 compilers went, but I'm
thinking they were some of the ones with segfaults).
For that matter, I bet that if you search the archives of this
newsgroup, you'll find a large fraction of the queries related to
recursive I/O are related to doing internal I/O in a function invoked
from an I/O statement. That's what I maintain is the most requested
case; I don't think the competition is even close.
Lane Straatman
"Richard Maine" <nos...@see.signature> wrote in message
news:1hvt9nq.1qrxrf7kz3eouN%nos...@see.signature...
have missed the relevant part of MR&C for this, as I have no model for how
it happens.
--
LS
Dan Nagle
I have seen C programmers rewriting inner loops for different chips,
for efficiency, not for correctness,
only to have a newer version of the compiler obviate the need
for the more complex code. The different kernels are then enshrined
in conditional compilation, adding to the complexity of the code.
--
Dan Nagle
Purple Sage Computing Solutions, Inc.
Pierre Asselin
> Pierre Asselin wrote:
> > Gordon Sande <g.s...@worldnet.att.net> wrote:
> >
> >> The story I have heard repeatedly is that C needs to be "updated" every
> >> time a new version of the vendors C compiler comes out. I have always
> >> understood that to be overly "clever" code although some claim that C
> >> encourages such behaviour.
> >
> > Gordon, I don't know where you get your information. This hasn't been
> > my experience at all. Nor with Fortran, for that matter.
> I have seen C programmers rewriting inner loops for different chips,
> for efficiency, not for correctness,
> only to have a newer version of the compiler obviate the need
> for the more complex code.
OK, I can see that. If your hardware and toolchain doesn't meet
your performance requirements you do what you have to do to squeeze
it out, even if it means micro-optimization. From what you say,
the compiler updates were an opportunity to *clean up* the code.
> The different kernels are then enshrined
> in conditional compilation, adding to the complexity of the code.
But the conditional compilation would be by chip, not by compiler
revision, wouldn't it ?
If you think Fortran is immune from micro-optimization, consider
a vanilla array-crunching app where performance is at a premium.
Let's say you found the bottleneck. Do you use
1) regular do loops ?
2) forall's ?
3) F90 array operations and matmul's ?
4) external BLAS calls ?
Anyone wants to convince me that the answer is independent
of compiler and CPU ?
(Well, maybe *one* of them can be ruled out,
http://www.fortran.bcs.org/2007/jubilee/f50.pdf)
Pierre Asselin
> Recursive io is news, a couple months ago, for this fortran refugee. I must
> have missed the relevant part of MR&C for this, as I have no model for how
> it happens.
integer function F(i)
integer i
F= I*I
write(6,"('F(',I3,')=',I6)") i, F
return
end
program main
print *, F(5)
end
Dan Nagle
Pierre Asselin wrote:
> Dan Nagle <dann...@verizon.net> wrote:
<snip>
> But the conditional compilation would be by chip, not by compiler
> revision, wouldn't it ?
No, it was compiler by compiler. The C compiler failed to use
both of two floating point pipelines due to pointer access
to an array.
> If you think Fortran is immune from micro-optimization, consider
> a vanilla array-crunching app where performance is at a premium.
I've never made such a claim, but I'll examine yours.
> Let's say you found the bottleneck. Do you use
> 1) regular do loops ?
> 2) forall's ?
> 3) F90 array operations and matmul's ?
> 4) external BLAS calls ?
The choice here depends upon so many different unstated details
that a summary in terms of 1) through 4) is impossible.
> Anyone wants to convince me that the answer is independent
> of compiler and CPU ?
If one considers optimization -O<n> as a function of <n>,
with almost any language and almost any compiler, increasing <n>
decreases standards compliance. C is handicapped by starting
in a deeper hole due to synchronization points,
explicit addresses, and, overall, the desired ability
to "see the hardware through the code".
Almost no matter what one's goal, portability, efficiency,
safety, or what have you, a higher level language is better
than a lower level language. Anyone wants to convince me
otherwise?
Richard Maine
> Lane Straatman <inv...@invalid.net> wrote:
>
> > Recursive io is news, a couple months ago, for this fortran refugee. I must
> > have missed the relevant part of MR&C for this, as I have no model for how
> > it happens.
>
[example elided]
Or below is a more realistic one, which involves internal I/O in what I
have described as the most-requested form. This is more or less a real
example. I've simplified it in several ways for expository purposes, but
the functionality is one that I have to work around the recursive I/O
restriction to do today. Off the top of my head from scratch, and
untested (well, as it uses recursive I/O, testing would fail on a
compiler that doesn't implement an extension anyway)
use my_module
...
real :: t = 12345.6
write (*,*) 'The time is ', time_string(t)
...
module my_module
implicit none
contains
function time_string(t)
!-- Convert time in seconds to a string in the form hh:mm:ss.mmm
!---------- interface.
real, intent(in) :: t
character*12 :: time_string
!---------- local.
integer :: it, hours, mins, secs, msecs
!---------- executable.
it = t
hours = it/3600
mins = mod(it,3600)/60
secs = mod(it,60)
msecs = (t-it)*1000
write(time_string,'(2(i2.2.":"),i2.2,".",i3i3)') &
hours, mins, secs, msecs
return
end function time_string
end module my_module
Gary Scott
It used to be very common to use inline assembly in Fortran to ensure
peak performance in device driver or interrupt handler code. I had
several applications where interrupt handlers and frame sync timers were
handled through inline assembly. I was never able to read the 1
microsecond interval timer faster than 2.5 microseconds though when the
documentation indicated that I should be able to sample each 1
microsecond clock tic. Never figured that out (I used two instructions
so maybe there was a way to get it to memory with just one instruction).
> 1) regular do loops ?
> 2) forall's ?
> 3) F90 array operations and matmul's ?
> 4) external BLAS calls ?
>
> Anyone wants to convince me that the answer is independent
> of compiler and CPU ?
>
> (Well, maybe *one* of them can be ruled out,
> http://www.fortran.bcs.org/2007/jubilee/f50.pdf)
>
>
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
glen herrmannsfeldt
(snip)
> I have seen C programmers rewriting inner loops for different chips,
> for efficiency, not for correctness,
You mean like Duff's device, though it apparently
is legal C.
http://en.wikipedia.org/wiki/Duff%27s_device
-- glen
robert....@sun.com
> Lane Straatman <inva...@invalid.net> wrote:
> > Recursive io is news, a couple months ago, for this fortran refugee. I must
> > have missed the relevant part of MR&C for this, as I have no model for how
> > it happens.
>
> integer function F(i)
> integer i
> F= I*I
> write(6,"('F(',I3,')=',I6)") i, F
> return
> end
>
> program main
> print *, F(5)
> end
Assuming * and 6 identify the same unit (a common occurrence),
this program is still not standard conforming.
Bob Corbett
robert....@sun.com
> For that matter, I bet that if you search the archives of this
> newsgroup, you'll find a large fraction of the queries related to
> recursive I/O are related to doing internal I/O in a function invoked
> from an I/O statement. That's what I maintain is the most requested
> case; I don't think the competition is even close.
I did the experiment you suggested. I searched for the phrase
"recursive I/O" in the group comp.lang.fortran on Google groups.
I got 80 hits. I examined each hit and I found that 37 hits
were irrelevant to the topic at hand, 24 concerned recursive I/O
involving files only, and 19 concerned recursive I/O involving
internal I/O.
Most of the irrelevant hits were irrelevant because they did
not discuss recursive I/O. Just because the words "recursive"
and "I/O" occur in a posting, it does not follow that the
posting is about recursive I/O. I categorize postings that
announced that Fortran 2003 now supports recursive I/O as
irrelevant. I also categorized postings asking "what is
recursive I/O?" as irrelevant. I categorized posting in this
thread as irrelevant.
I was generous in categorizing postings as involving internal
I/O. In a large number of the threads that contributed to
that category, the OP asked a question such as "how do I
convert a number into its character representation?", and a
respondent would say to use internal I/O use internal I/O
but be careful of recursive I/O. I categorized such threads
as concerning recursive I/O involving internal I/O.
Bob Corbett
robert....@sun.com
> I did the experiment you suggested. I searched for the phrase
> "recursive I/O" in the group comp.lang.fortran on Google groups.
> I got 80 hits. I examined each hit and I found that 37 hits
> were irrelevant to the topic at hand, 24 concerned recursive I/O
> involving files only, and 19 concerned recursive I/O involving
> internal I/O.
I suspect the reason the result turned out as it did is that
many Fortran users do not make much use of internal I/O
(hence the questions about how to convert numbers to strings),
but everyone knows how to do WRITE-statement debugging.
Bob Corbett
Gary Scott
> On Apr 1, 2:23 am, robert.corb...@sun.com wrote:
>
>
>>I did the experiment you suggested. I searched for the phrase
>>"recursive I/O" in the group comp.lang.fortran on Google groups.
>>I got 80 hits. I examined each hit and I found that 37 hits
>>were irrelevant to the topic at hand, 24 concerned recursive I/O
>>involving files only, and 19 concerned recursive I/O involving
>>internal I/O.
>
>
> I suspect the reason the result turned out as it did is that
> many Fortran users do not make much use of internal I/O
Goodness, it would be surprising if it were a "many". Most Fortran
programs that I've surveyed within my company involve internal I/O.
> (hence the questions about how to convert numbers to strings),
> but everyone knows how to do WRITE-statement debugging.
>
> Bob Corbett
>
Pierre Asselin
> Pierre Asselin wrote:
> > Dan Nagle <dann...@verizon.net> wrote:
> <snip>
> > But the conditional compilation would be by chip, not by compiler
> > revision, wouldn't it ?
> No, it was compiler by compiler. The C compiler failed to use
> both of two floating point pipelines due to pointer access
> to an array.
I'm just trying to understand. Your data point was
> I have seen C programmers rewriting inner loops for different chips,
> for efficiency, not for correctness,
ok so far, unfortunate but sometimes necessary
> only to have a newer version of the compiler obviate the need
> for the more complex code.
at which point they can toss the more complex code. But,
> The different kernels are then enshrined
> in conditional compilation, adding to the complexity of the code.
This is the part I don't understand. They kept the ugly code
under ifdefs instead of throwing it away ? Why did they feel
the need to support superseded compilers ? Were they shipping
source ?
Dan Nagle
Pierre Asselin wrote:
> Dan Nagle <dann...@verizon.net> wrote:
<snip>
> I'm just trying to understand. Your data point was
>
>> I have seen C programmers rewriting inner loops for different chips,
>> for efficiency, not for correctness,
>
> ok so far, unfortunate but sometimes necessary
But done when necessary.
>> only to have a newer version of the compiler obviate the need
>> for the more complex code.
>
> at which point they can toss the more complex code.
But they rarely do. The ugly code is tested, it works,
and it just might be necessary later. Besides, it shows
how smart the programmer was for having thought of it.
How many programmers fix things that work?
> But,
>
>> The different kernels are then enshrined
>> in conditional compilation, adding to the complexity of the code.
>
> This is the part I don't understand. They kept the ugly code
> under ifdefs instead of throwing it away ?
Yes. Again, do you fix things that work?
> Why did they feel
> the need to support superseded compilers ?
The older compiler may be used again. Not everyone
moves to the latest and greatest on day one. Or a bug
might be found in the newer compiler.
> Were they shipping
> source ?
Yes.
Dick Hendrickson
> On 2007-03-30 10:42:11 -0300, Ben Hetland <ben.a....@sintef.no> said:
>
>> Gordon Sande wrote:
>>> Some FFT codes that I wrote in 1966 are still in use in standard
>>> X-ray crystallography packages if I believe my chemist friends.
>>> That makes 41 years.
>>
>> And that is to be interpreted as _unchanged_ source for these 41 years?
>
> Yes. Interestingly the code was writen as an exercise in exposition
> with efficiency as a secondary objective. The resulting style meant
> that there were absolutely no "clever" tricks. The efficiency turned
> out to be first rate as well.
That parallels an interesting "experiment" I took part in the 70s and
early 80s when I worked at Cray Research. The early Cray computers
had a "vector" mode that would run a loop 5 or 10 times faster than
the corresponding "scalar" mode. Since none of the competitors had
a vector mode, this was a commercial advantage and the compiler
spent a lot of time looking for vectorizable loops. The early
compilers had trouble with complicated subscripts and control flows.
Most users (and many benchmarkers) rewrote their time-critical loops
into a simplier form that the compiler would vectorize. The surprising,
to me anyhow, fact was that these codes also ran faster in scalar mode
on both Cray machines and on the customers original machines. Clean
and simple is a good idea.
Dick Hendrickson
Dick Hendrickson
[snip]
> I categorized posting in this thread as irrelevant.
> Bob Corbett
>
Gee Bob, I know you posted this on April fool's day, but isn't that
a little harsh?
Dick Hendrickson
Rich Townsend
> Hi
> I was wondering if its a good idea to start learning to program
> fortran and why?
> is it better or faster than C??
> thanks
> Chris
>
Yes, so long as you avoid accessing arrays in the wrong order.
Michael Delaney
> Most folks consider the ability to grab the internals out of C expressions
> with embedded assignments as a prime example of a write only language
> for hackers. The collection of += type symbols have no equivalent in
> conventional mathematical notation so need explanation as to their
> semantics, particularly with && and such. Programming is an area where
> clever is often a rather bad thing and you seem to be like a lot of
> features that encourage cleverness at its worst.
pffft!
--
Most "scientists" are bottle washers and button sorters.
-- Robert A. Heinlein
Terence
reminds me of AAA members going to the help of a friend about to fall
off the wagon!
Doubting Fortran indeed?
I think the simpler earlier form "FORTRAN" was amazingly good enough
for strucure and problem-defining although F77 was a vast improvement.
F90 I've used; F95 was a cosmetic improvrment and the absence of 2003
compilers speaks words for what the industry thinks of it.
But I always wanted screen control (that never came) and better
ability to define output formats, but on the whole I haven't seen any
other language that comes close for ease and scope.
Beliavsky
> The original title of this thread plus the huge (knee-jerk?) response
> reminds me of AAA members going to the help of a friend about to fall
> off the wagon!
> Doubting Fortran indeed?
>
> I think the simpler earlier form "FORTRAN" was amazingly good enough
> for strucure and problem-defining although F77 was a vast improvement.
> F90 I've used; F95 was a cosmetic improvrment and the absence of 2003
> compilers speaks words for what the industry thinks of it.
Nonsense. Fortran 2003 has added many new features to the language,
and implementing them will take time.
Most of the vendors of Fortran 95 compilers are adding features of
Fortran 2003, with Salford/Silverfrost and (probably) Lahey/Fujitsu
being exceptions. Yesterday I updated my Intel Visual Fortran compiler
to 9.1.036 . Quoting the release notes,
"The Intel Fortran Compiler supports many features that are new to the
latest revision of the Fortran standard, Fortran 2003. Additional
Fortran 2003 features will appear in future versions. Fortran 2003
features supported by the current compiler include:
The Fortran character set has been extended to contain the 8-bit ASCII
characters ~ \ [ ] ` ^ { } | # @
Names of length up to 63 characters
Statements of up to 256 lines
Square brackets [ ] are permitted to delimit array constructors
instead of (/ /)
A named PARAMETER constant may be part of a complex constant
Allocatable components of derived types
BIND(C) attribute and statement
PROTECTED attribute and statement
VALUE attribute and statement
VOLATILE attribute and statement
INTENT attribute for pointer objects
In all I/O statements, the following numeric values can be of any
kind: UNIT=, IOSTAT=
FLUSH statement
The following OPEN numeric values can be of any kind: RECL=
The following READ and WRITE numeric values can be of any kind: REC=,
SIZE=
The following INQUIRE numeric values can be of any kind: NEXTREC=,
NUMBER=, RECL=, SIZE=
Recursive I/O is allowed in the case where the new I/O being started
is internal I/O that does not modify any internal file other than its
own
IEEE Infinities and NaNs are displayed by formatted output as
specified by Fortran 2003
In an I/O format, the comma after a P edit descriptor is optional when
followed by a repeat specifier
Rename of user-defined operators in USE
IMPORT statement
Allocatable dummy arguments
Allocatable function results
COMMAND_ARGUMENT_COUNT intrinsic
GET_COMMAND intrinsic
GET_COMMAND_ARGUMENT intrinsic
GET_ENVIRONMENT_VARIABLE intrinsic
IS_IOSTAT_END intrinsic
IS_IOSTAT_EOR intrinsic
MOVE_ALLOC intrinsic
NEW_LINE intrinsic
SELECTED_CHAR_KIND intrinsic
The following intrinsics take an optional KIND= argument: ACHAR,
COUNT, IACHAR, ICHAR, INDEX, LBOUND, LEN, LEN_TRIM, MAXLOC, MINLOC,
SCAN, SHAPE, SIZE, UBOUND, VERIFY"
glen herrmannsfeldt
Gordon Sande wrote:
> Most folks consider the ability to grab the internals out of C
> expressions
> with embedded assignments as a prime example of a write only language
> for hackers. The collection of += type symbols have no equivalent in
> conventional mathematical notation so need explanation as to their
> semantics, particularly with && and such. Programming is an area where
> clever is often a rather bad thing and you seem to be like a lot of
> features that encourage cleverness at its worst.
The C assignment operators can be overused, and result in some
hard to read code. On the other hand, for assignments with
a complicated left side it is often much more readable. Consider:
x(2*i-1,j+k-3,int(sqrt(y))) = x(2*i-1,j+k-3,int(sqrt(y))) + z
How long does it take to verify that the subscripts are the
same on both sides of the equal sign? (I copied it so I know
they are, but how do you know that?)
Now, consider:
x[2*i-1][j+k-3][(int)sqrt(y)] += z;
You don't have to check that two sets of expressions are the
same, and can be reasonably sure that they won't be evaluated
twice.
-- glen
Dan Nagle
glen herrmannsfeldt wrote:
<snip>
> x(2*i-1,j+k-3,int(sqrt(y))) = x(2*i-1,j+k-3,int(sqrt(y))) + z
<snip>
> x[2*i-1][j+k-3][(int)sqrt(y)] += z;
>
> You don't have to check that two sets of expressions are the
> same, and can be reasonably sure that they won't be evaluated
> twice.
But doesn't that make the two _not_ equivalent?
Suppose one of your function references in the above
is impure. Then the value returned may differ
in subsequent evaluations. Recall that C doesn't guarantee
whether the LHS or the RHS is evaluated first.
Richard Harter
wrote:
IIANM in that case the full expression is an instance of undefined
behaviour.
Dan Nagle
Richard Harter wrote:
<snip>
> IIANM in that case the full expression is an instance of undefined
> behaviour.
Yes, see Annex J of ISO 9899, where the order of evaluation
is listed as a portability issue.
glen herrmannsfeldt
(I wrote)
>>>x(2*i-1,j+k-3,int(sqrt(y))) = x(2*i-1,j+k-3,int(sqrt(y))) + z
(and)
>>>x[2*i-1][j+k-3][(int)sqrt(y)] += z;
>>>You don't have to check that two sets of expressions are the
>>>same, and can be reasonably sure that they won't be evaluated
>>>twice.
>>But doesn't that make the two _not_ equivalent?
>>Suppose one of your function references in the above
>>is impure. Then the value returned may differ
>>in subsequent evaluations. Recall that C doesn't guarantee
>>whether the LHS or the RHS is evaluated first.
> IIANM in that case the full expression is an instance of undefined
> behaviour.
Since the first is not legal C, and the second not legal Fortran,
and there is only one function reference in the C code, it isn't
so obvious what he is asking. The Fortran statement does have
two function evaluations, what does Fortran say about that?
-- glen
Pierre Asselin
> glen herrmannsfeldt wrote:
> <snip>
> > x(2*i-1,j+k-3,int(sqrt(y))) = x(2*i-1,j+k-3,int(sqrt(y))) + z
> <snip>
> > x[2*i-1][j+k-3][(int)sqrt(y)] += z;
> But doesn't that make the two _not_ equivalent?
Indeed, for the reason you give.
> Suppose one of your function references in the above
> is impure. Then the value returned may differ
> in subsequent evaluations. Recall that C doesn't guarantee
> whether the LHS or the RHS is evaluated first.
Neither does Fortran, If I understand 97-007R2 correctly.
R735 _assignment-stmt_ is _variable_ = _expr_
7.5.1.5 Interpretation of Intrinsic assignments
[ ... ] the evaluation of expressions within _variable_ shall
neither affect of be affected by the evaluation of _expr_.
So if one of the index expressions has an impure function call,
the first example fails to be standard-conforming in both Fortran
and C.
If you read Glen's conclusion,
> glen herrmannsfeldt wrote:
> >
> > You don't have to check that two sets of expressions are the
> > same, and can be reasonably sure that they won't be evaluated
> > twice.
he was pointing out *two* advantages of the "+=" operator (in this
type of statement).
James Giles
...
> The C assignment operators can be overused, and result in some
> hard to read code. On the other hand, for assignments with
> a complicated left side it is often much more readable. Consider:
>
> x(2*i-1,j+k-3,int(sqrt(y))) = x(2*i-1,j+k-3,int(sqrt(y))) + z
>
> How long does it take to verify that the subscripts are the
> same on both sides of the equal sign? (I copied it so I know
> they are, but how do you know that?)
>
> Now, consider:
>
> x[2*i-1][j+k-3][(int)sqrt(y)] += z;
>
> You don't have to check that two sets of expressions are the
> same, and can be reasonably sure that they won't be evaluated
> twice.
Even clearer of course is
loc1 = 2*i-1; loc2 = j+k-3; loc3 = int(sqrt(y))
x(loc1,loc2,loc3) = x(loc1,loc2,loc3)+z
Programming for clarity isn't about minimizing keystrokes.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
glen herrmannsfeldt
(snip)
> Even clearer of course is
> loc1 = 2*i-1; loc2 = j+k-3; loc3 = int(sqrt(y))
> x(loc1,loc2,loc3) = x(loc1,loc2,loc3)+z
Hard to say for me.
Temporary variables leave the question of where else they
might be used. You still need to verify that the two are
the same, though it should be pretty fast.
(and reminds me of the temporary variables needed for WRITE
statements in Fortran 66.)
> Programming for clarity isn't about minimizing keystrokes.
I won't disagree with this one.
-- glen
Gary Scott
> glen herrmannsfeldt wrote:
> ...
>
>>The C assignment operators can be overused, and result in some
>>hard to read code. On the other hand, for assignments with
>>a complicated left side it is often much more readable. Consider:
>>
>>x(2*i-1,j+k-3,int(sqrt(y))) = x(2*i-1,j+k-3,int(sqrt(y))) + z
>>
>>How long does it take to verify that the subscripts are the
>>same on both sides of the equal sign? (I copied it so I know
>>they are, but how do you know that?)
>>
>>Now, consider:
>>
>>x[2*i-1][j+k-3][(int)sqrt(y)] += z;
>>
>>You don't have to check that two sets of expressions are the
>>same, and can be reasonably sure that they won't be evaluated
>>twice.
>
>
> Even clearer of course is
>
> loc1 = 2*i-1; loc2 = j+k-3; loc3 = int(sqrt(y))
> x(loc1,loc2,loc3) = x(loc1,loc2,loc3)+z
>
> Programming for clarity isn't about minimizing keystrokes.
>
heck, even I can understand this one
Gordon Sande
> glen herrmannsfeldt wrote:
> ...
>> The C assignment operators can be overused, and result in some
>> hard to read code. On the other hand, for assignments with
>> a complicated left side it is often much more readable. Consider:
>>
>> x(2*i-1,j+k-3,int(sqrt(y))) = x(2*i-1,j+k-3,int(sqrt(y))) + z
>>
>> How long does it take to verify that the subscripts are the
>> same on both sides of the equal sign? (I copied it so I know
>> they are, but how do you know that?)
>>
>> Now, consider:
>>
>> x[2*i-1][j+k-3][(int)sqrt(y)] += z;
>>
>> You don't have to check that two sets of expressions are the
>> same, and can be reasonably sure that they won't be evaluated
>> twice.
>
> Even clearer of course is
>
> loc1 = 2*i-1; loc2 = j+k-3; loc3 = int(sqrt(y))
> x(loc1,loc2,loc3) = x(loc1,loc2,loc3)+z
>
> Programming for clarity isn't about minimizing keystrokes.
Although in the really bad old days of 300 baud connections
with a mechanical typewriter (Teletype model 33 comes to mind)
the reduction of keystrokes was an objective for some. Shorter
listings (in print time) as well.
C had its origins in exactly that environment. The PDP-x
machines had an increment to memory command so += was quite
natural.
I once worked with some folks who had a very early PDP-8 that had
a curious problem that it kept modifying memory. They eventually
tracked the problem down to a particular connection on the backplane.
When they asked the more senior techs at DEC what it was all about
they got a hearty laugh and "Oh! you got one that was wired as a pulse
height analyzer." The folks thought it was a good story even at their
expense but did claim that they sure knew how PDP-8s worked after
the trouble they went to in finding the "problem". The increment to
memory commands have uses other than just being atomic for locks etc.
Dan Nagle
glen herrmannsfeldt wrote:
<snip>
> Since the first is not legal C, and the second not legal Fortran,
> and there is only one function reference in the C code, it isn't
> so obvious what he is asking. The Fortran statement does have
> two function evaluations, what does Fortran say about that?
Evaluating any part of an expression is not allowed to change
any other part of the expression. But in Fortran, the expression
is the RHS. The = is not an operator. This is one source
of subtle difference between Fortran and C.
Richard Maine
> Evaluating any part of an expression is not allowed to change
> any other part of the expression. But in Fortran, the expression
> is the RHS.
Woah. Let's slow down a little and get it right here. There are areas
where people disagree about the fine points of interpretation of
function side effects, but this isn't one of those areas. This is among
the most straightforward cases, so we can get it right.
First note that there are expressions multiple places in this statement
- not just on the RHS. The ones on the LHS aren't part of the same
expression, but they are stll expressions. You don't always have
expressions involved in the LHS, but this example does.
However, all that is irrelevant anyway because you misquoted the rule in
question. The rule does not actually contain the word "expression" at
all, so getting off into what is part of "the expression" is moot. From
f95 7.1.7
"The evaluation of a function reference shall neither affect nor be
affected by the evaluation of any other entity within the statement."
Note the absence of any mention of "expression". Note instead the word
"statement". Both the RHS and LHS are part of the same statement. Thus
neither function evaluation may affect the other. If there is such an
effect, the code is illegal. If there is no such effect, the code is
fine and order of evaluation doesn't matter.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Klaus Wacker
> James Giles wrote:
>
> (snip)
>
>> Even clearer of course is
>
>> loc1 = 2*i-1; loc2 = j+k-3; loc3 = int(sqrt(y))
>> x(loc1,loc2,loc3) = x(loc1,loc2,loc3)+z
>
> Hard to say for me.
>
> Temporary variables leave the question of where else they
> might be used. You still need to verify that the two are
> the same, though it should be pretty fast.
> (and reminds me of the temporary variables needed for WRITE
> statements in Fortran 66.)
And for array indices. loc1 would not be needed IIRC, but loc2 and
loc3 would.
--
Klaus Wacker klaus....@udo.edu
Experimentelle Physik V http://www.physik.uni-dortmund.de/~wacker
Universitaet Dortmund Tel.: +49 231 755 3587
D-44221 Dortmund Fax: +49 231 755 4547
Pierre Asselin
> On 2007-04-06 14:40:26 -0300, "James Giles" <james...@worldnet.att.net> said:
> >
> > Programming for clarity isn't about minimizing keystrokes.
> Although in the really bad old days of 300 baud connections
> with a mechanical typewriter (Teletype model 33 comes to mind)
> the reduction of keystrokes was an objective for some. Shorter
> listings (in print time) as well.
> C had its origins in exactly that environment. The PDP-x
> machines had an increment to memory command so += was quite
> natural.
According to Dennis Ritchie, += came from Algol 68.
http://cm.bell-labs.com/cm/cs/who/dmr/chist.html
Lane Straatman
"Pierre Asselin" <p...@see.signature.invalid> wrote in message
news:ev6ote$kik$1...@reader2.panix.com...
one.
--
LS
James Giles
> James Giles wrote:
>
> (snip)
>
>> Even clearer of course is
>
>> loc1 = 2*i-1; loc2 = j+k-3; loc3 = int(sqrt(y))
>> x(loc1,loc2,loc3) = x(loc1,loc2,loc3)+z
>
> Hard to say for me.
>
> Temporary variables leave the question of where else they
I suppose you *could* characterize that as a disadvantage.
On the other hand, suppose you had several variables the same
shape as X that you wanted to do corresponding things to.
Creating the temporaries allow the corresponding location
in each to be easily verified as correct.
p(loc1, loc2, loc3) = ...
q(loc1, loc2, loc3) = ...
...
> ...] You still need to verify that the two are
> the same, though it should be pretty fast.
I've used something like my old preprocessor (patterned
on Ken Kennedy's linear subscript transform ideas) where
you could define a single subsrcipt expression:
@loc = (2*i-1, j+k-3, int(sqrt(y))
x@loc = x@loc + z
This retains the advantage of using the same "slice" for more
than one array:
p@loc = ...
q@loc = ...
...
Of course, for the original problem you could use Fortran pointers
(assuming that X has the target attribute):
px => x(2*i-1, j+k-3, int(sqrt(y))
px = px +z
This has several disadvantages, including the fact that you can't
use the same expression for multiple corresponding arrays (for
that you'd need multiple pointers, or multiple uses of the same
pointer). Still, it solves this particular issue with clarity.
There's really nothing particularly wrong with compound assignment
operators like +=. It's a matter of judgemment. I think they add more
complexity to the language than is justified by their value. And C's
version of them is considered an expression level operator rather
than one-per-statement. I find confusing:
x = (var+=val)*7
More elaborate expressions containing several assignments are not
uncommon. I suppose it's little different from having functions with
side-effects.
glen herrmannsfeldt
(snip)
> There's really nothing particularly wrong with compound assignment
> operators like +=. It's a matter of judgemment. I think they add more
> complexity to the language than is justified by their value. And C's
> version of them is considered an expression level operator rather
> than one-per-statement. I find confusing:
> x = (var+=val)*7
I agree that is confusing, and I wouldn't use it.
More common is using such operators on pointers or as subscripts.
x[i+=2] = x[j+=3];
Still confusing, but maybe not quite as bad.
> More elaborate expressions containing several assignments are not
> uncommon. I suppose it's little different from having functions with
> side-effects.
Well, using the value of assignment also allows multiple assignment:
i=j=k=0;
that isn't so confusing.
-- glen
Ron Shepard
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Well, using the value of assignment also allows multiple assignment:
>
> i=j=k=0;
>
> that isn't so confusing.
Not until i, j, and k have different types, and then you initiate
endless arguments about which interpretation is correct.
$.02 -Ron Shepard
James Giles
Assignment is right associative. So it's the same as:
i = (j = (k = 0));
James Giles
...
> Well, using the value of assignment also allows multiple assignment:
>
> i=j=k=0;
>
> that isn't so confusing.
Well, for that I prefer my own:
(i, j, k) = 0
The left is a list constuctor, the right a scalar zero. Like Fortran
arrays, scalars are assignment conformable to lists by being
broadcast to the whole list. I like this better, especially if the
types of i, j, and k are not all the same. Suppose you write:
i=j=k=0.1;
And further suppose k is an integral type and the others are
floats of some precision. The above will actually assign
zero to all three variables, since assigning to an integer
truncates. On the other hand:
(i, j, k) = 0.1
is identical to:
i = 0.1; j = 0.1; k = 0.1
The list form has some other (trivial) advantages. The following
is a swap:
(a, b) = (b, a)
It's merely syntactic sugar. I doubt it's worth the effort it takes
to get the implementation right. But, having done it, I like it.