Fortran90 better than Fortran77 ??
Ming R Tse
Hi,
I am learning how to rewrite codes in Fortran 90 . Moreover, I am going
to modify from my codes which were written in Fortran 77 to Fortran 90.
Could anyone tell me how Fortran 90 is better than Fortran 77 ? Can you
give me some examples show me what the advantages are ??
Thanks.
Ming R Tse
ray...@eng.iastate.edu
Vivek Rao
Try reading the online tutorial
"Fortran 90 for the Fortran 77 Programmer" at
http://www.nsc.liu.se/f77to90.html . Other tutorials are listed
at http://www.fortran.com/fortran/tutorials.html .
Vivek Rao
Albert Israel
--------------BEA263157D70860E8070F4BA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ming R Tse wrote:
> Hi,
>
> I am learning how to rewrite codes in Fortran 90 . Moreover, I am going
> to modify from my codes which were written in Fortran 77 to Fortran 90.
> Could anyone tell me how Fortran 90 is better than Fortran 77 ? Can you
> give me some examples show me what the advantages are ??
>
> Thanks.
>
> Ming R Tse
> ray...@eng.iastate.edu
Hi
You can look at my web page which also gives a short crash course on
Fortran90. There
are a number of advantages of fortrn77 over fortran90. One can define new
datatypes
much like C or C++ can do data abstraction, overload operators, do dynamic memory
allocation,
use pointers etc.
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/_/ _/ _/ _/ _/ _/
_/ Albert Israel _/ _/ _/ _/ _/ _/ _/
_/ Department of Chemistry _/ _/ _/ _/ _/ _/ _/ _/
_/ Northwestern University _/ _/ _/ _/ _/_/ _/ _/ _/
_/ Evanston, IL 60208 _/ _/_/ _/_/ _/_/ _/_/
_/ WWW: http://www.chem.nwu.edu/~albert EMAIL: alb...@chem.nwu.edu
_/ phone: (847) 491-3423 fax: (847) 491-7713
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
--------------BEA263157D70860E8070F4BA
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
Ming R Tse wrote:
<BLOCKQUOTE TYPE=CITE>Hi,
<P> I am learning how to rewrite
codes in Fortran 90 . Moreover, I am going
<BR>to modify from my codes which were written in Fortran 77 to Fortran
90.
<BR>Could anyone tell me how Fortran 90 is better than Fortran 77 ? Can
you
<BR>give me some examples show me what the advantages are ??
<P>Thanks.
<P>Ming R Tse
<BR>ray...@eng.iastate.edu</BLOCKQUOTE>
Hi
<P> You can look at my web page which also gives a short
crash course on Fortran90. There
<BR>are a number of advantages of fortrn77 over fortran90. One can
define new datatypes
<BR>much like C or C++ can do data abstraction, overload operators, do
dynamic memory allocation,
<BR>use pointers etc.
<PRE>--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/_/ _/ _/ _/ _/ _/
_/ Albert Israel _/ _/ _/ _/ _/ _/ _/
_/ Department of Chemistry _/ _/ _/ _/ _/ _/ _/ _/
_/ Northwestern University _/ _/ _/ _/ _/_/ _/ _/ _/
_/ Evanston, IL 60208 _/ _/_/ _/_/ _/_/ _/_/
_/ WWW: <A HREF="http://www.chem.nwu.edu/~albert">http://www.chem.nwu.edu/~albert</A> EMAIL: alb...@chem.nwu.edu
_/ phone: (847) 491-3423 fax: (847) 491-7713
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/</PRE>
</HTML>
--------------BEA263157D70860E8070F4BA--
LC's No-Spam Newsreading account
On Tue, 30 Sep 1997, Albert Israel wrote:
> are a number of advantages of fortrn77 over fortran90. One can define new
[...]
> use pointers etc.
^^^^^^^^^^^^
is that REALLY an advantage ?
----------------------------------------------------------------------
nos...@ifctr.mi.cnr.it is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.
James Giles
Ralph Jay Frisbie <rfri...@vcnet.com> wrote in article
<343356...@vcnet.com>...
> LC's No-Spam Newsreading account wrote:
[...]
> > > use pointers etc.
> > ^^^^^^^^^^^^
> >
> > is that REALLY an advantage ?
> >
> snip
> Yes, because it is OPTIONAL. Hence, an algorithm which needs them,
> linked lists for instance, has them. But, they are not necessary if you
> don't wish to use them. Some other languages force one to be aware of
> pointers, in Fortran they are a nice option, if you wish.
I've used linked lists in Fortran for years and usually without pointers.
For the purpose of linked lists (in which array slicing and such is
not relevant), pointers are just indices into an unrestricted range
(of all of memory). Since the elements of any individual list do not
occupy all of memory, they can be collected into a common area
(an array, for example) and the links can be maintained as indices
into that area only rather than to all of memory. So, pointers might
have a relatively minor optimization benefit (or deficit) depending on
the hardware and/or compiler you're using, but you don't need them
for the functionality.
--
J. Giles
Ricercar Software
Ian Chivers
In article <343356...@vcnet.com>, Ralph Jay Frisbie <rfri...@vcnet.com> writes:
> LC's No-Spam Newsreading account wrote:
>>
>>
>> > are a number of advantages of fortrn77 over fortran90. One can define new
>> > use pointers etc.
>> ^^^^^^^^^^^^
>>
>> is that REALLY an advantage ?
>>
> snip
> Yes, because it is OPTIONAL. Hence, an algorithm which needs them,
> linked lists for instance, has them. But, they are not necessary if you
> don't wish to use them. Some other languages force one to be aware of
> pointers, in Fortran they are a nice option, if you wish.
> _______________________________
> | Ralph Jay Frisbie |
> | |
> | a saucer lover, |
> | but not the inventor! |
> | |
> | rfri...@vcnet.com |
> | 805-671-9989 |
> |______________________________|
as i posted in an earlier c++ example passing 2d arrays and above
as a function argument
requires the use in c++ of pointers.
as an argument to a function you HAVE to specify the 2nd and
additional array bounds explicitly.
only the first is open.
as ralph says you only have to use pointers when
you need them - e.g. linked lists.
ian chivers
king's college
london
Ralph Jay Frisbie
Kenneth Plotkin
In article <343356...@vcnet.com>,
Ralph Jay Frisbie <rfri...@vcnet.com> wrote:
> Yes, because it is OPTIONAL. Hence, an algorithm which needs them,
Optional only if you work by yourself or in a very tightly controlled
environment. A huge amount of Fortran is written by one engineer, then
downstream another engineer inherits the code and has to do something with
it. So you eventually do need to learn everything, like it or not.
Loading Fortran up with all of this stuff also steepens the learning
curve. I've got a young physicist working for me who is driving me nuts.
He's learning Fortran, and he seems to be hell-bent on using every odd
trick he can find. He's stumbling over the basics, and confusing things
by even worse trying to be fancy. Part of the problem is that he's just
got an exploring attitude to whatever he does, and part of it is that he's
overwhelmed with all of the stuff that's now in Fortran.
I see a lot of questions in this NG about how to use some of the more
esoteric features of F90. They don't seem to be from real programmers;
probably graduate students or maybe young engineers. I can't figure out
why anybody would need to do some of the things they are trying. I feel
great sympathy for the next engineer or graduate student who comes along
and tries to continue.
Ken Plotkin
Peter Shenkin
Kenneth Plotkin wrote:
>
> In article <343356...@vcnet.com>,
> Ralph Jay Frisbie <rfri...@vcnet.com> wrote:
> Loading Fortran up with all of this stuff also steepens the learning
> curve.
Versatility is the enemy of comprehensibility.
> I've got a young physicist working for me who is driving me nuts.
> He's learning Fortran, and he seems to be hell-bent on using every odd
> trick he can find.
Send him to a programming course, or buy him a good book, or have
him use F.
> I see a lot of questions in this NG about how to use some of the more
> esoteric features of F90. They don't seem to be from real programmers;
> probably graduate students or maybe young engineers.
Please give an example. Things like modules, automatic arrays, ALLOCATE
and array notation are very simple and very useful. It took me about
a day to learn to use them, at least in simple ways. Structures are
also pretty simple. Pointers are harder, so forget them until/unless
you really need them -- and not everyone does.
I remember, years ago, when first learning Fortran, that I longed for
opportunities to use features like alternate return. It was years
later that I finally figured out that not everything in a language is
really there for a sensible purpose. A lot of the "features" are
experiments that somebody thought would be a great idea, but concerning
which we now know better. One goal should be to write clear programs,
which sometimes means using the fewest language features possible (if
you pick the right ones :-) ).
Also, though I denigrate the idea that a programming language
is a "language" in the sense that English and French are languages,
it is nevertheless true that programming is a craft not unlike
writing prose. Style counts. It's as unrealistic to expect a
B.S. computer scientist or engineer to be a good programmer as it
is to expect a B.A. English major to be a good writer.
> ... I can't figure out
> why anybody would need to do some of the things they are trying. I feel
> great sympathy for the next engineer or graduate student who comes along
> and tries to continue.
Well, why don't you try explaining this to your young engineer? Not
everything that *can* be done *should* be done. A beginning programmer
needs much more than just a language syntax book; that's like saying
that all you need to write prose is a grammar. Why not supply some
good, non-trivial examples? Or give him assignment to write a program
or subroutine that does what your example does, but show him the
example only after he's written his version. Yes, you have to ask "Does
it do what it's supposed to do", but you also have to ask, "If I don't
know what it's supposed to do, can I figure it out from the comments
and the code?"
One more comment. Most texts have to describe the whole language.
The result is that features which for the most part should be
ignored or even avoided get as much treatment as parts which are
essential. One needs a "guide to the perplexed" (or "to those
who ought to be perplexed, but don't realize it"), perhaps
in the form of a more experienced programmer.
-P.
--
******************* Jimmy Witherspoon, 1923 - 1997, RIP
*******************
* Peter S. Shenkin; Chemistry, Columbia U.; 3000 Broadway, Mail Code
3153 *
** NY, NY 10027; she...@columbia.edu; (212)854-5143; FAX: 678-9039
***
*MacroModel WWW page:
http://www.columbia.edu/cu/chemistry/mmod/mmod.html *
N8TM
My department still depends on codes in which the programmer seems to have used
ASSIGN simply because it is there, and concentrated that use in the few
sections which would benefit from optimization. I found it well worth while
but laborious to get rid of these. Now some of the newer compilers refuse to
optimize code which contains arithmetic IF as well. No big loss, but why
don't they issue a comment indicating that they are dropping level of
optimization due to presence of obsolete syntax? That would speed up the
education process.
Tim
Kenneth Plotkin
In article <343407...@still3.chem.columbia.edu>,
Peter Shenkin <she...@still3.chem.columbia.edu> wrote:
>Versatility is the enemy of comprehensibility.
Definitely. And creativity is the enemy of obedience. Finding the right
place between the two is a struggle.
>Send him to a programming course, or buy him a good book, or have
>him use F.
I gave him my copy of Metcalf's "Effective Fortran 77". He used it as a
coaster under his coffee cup. :-( F won't work since he's got to use the
same compiler as the rest of us and it's got to match libraries that we
use. I have told him to stick to F77 features. The cooler F90 and F95
things and non-standard intrinsics do attract him like a moth to a flame.
>Please give an example. Things like modules, automatic arrays, ALLOCATE
>and array notation are very simple and very useful. It took me about
>a day to learn to use them, at least in simple ways. Structures are
>also pretty simple. Pointers are harder, so forget them until/unless
[snip]
Pointers. I see posts with titles that seem to be about ALLOCATE, but the
question turns out to be about pointers. Very often the context seems to
be one where ALLOCATE would be enough. I also see a surprising number of
posts about KIND.
>I remember, years ago, when first learning Fortran, that I longed for
>opportunities to use features like alternate return. It was years
>later that I finally figured out that not everything in a language is
>really there for a sensible purpose. A lot of the "features" are
[snip]
When I learned Fortran in the early 60s, I'd hang out in the keypunch room
with the real programmers. They'd show me assembly language and various
tricks. Self modifying code. Speeding up function calls by saving only
one index register instead of all three. Fortunately, my attention span
was too short to catch onto most of that.
In fact, when I think about the quantity of stuff I had to learn then, and
the quantity of stuff in F90, I wonder if I'd have ever learned Fortran if
I were doing it from scratch today.
>Also, though I denigrate the idea that a programming language
>is a "language" in the sense that English and French are languages,
[snip]
I remember some graduate school committees that almost let a programming
language satisfy foreign language requirements. :-\
>it is nevertheless true that programming is a craft not unlike
>writing prose. Style counts. It's as unrealistic to expect a
>B.S. computer scientist or engineer to be a good programmer as it
>is to expect a B.A. English major to be a good writer.
[snip]
Definitely a craft. And the quality of the result comes from the skill of
the doer, and not simply from the features of the language.
>Well, why don't you try explaining this to your young engineer? Not
>everything that *can* be done *should* be done. A beginning programmer
>needs much more than just a language syntax book; that's like saying
>that all you need to write prose is a grammar. Why not supply some
>good, non-trivial examples? Or give him assignment to write a program
[snip]
I've got him working a a project that needs modification to a fairly small
program - about 100 lines. He's using the program to help make sense of
some data that somebody else collected. I critique what he does as he
does it, and also critique what I should have done better in my part
before he arrived. Sometimes I leave him alone til he gets confused.
Depends on my mood and what I think will help him learn. Sometimes I
start sounding like my mother. :-(
>essential. One needs a "guide to the perplexed" (or "to those
>who ought to be perplexed, but don't realize it"), perhaps
>in the form of a more experienced programmer.
Guide to the perplexed - that's my part in this. BTW, when my boss (of
many years) sees me struggling to channel a bright young guy in productive
directions, he gets this funny little smile....
Ken Plotkin
Dick Hendrickson
Kenneth Plotkin wrote:
>
> In article <343407...@still3.chem.columbia.edu>,
> Peter Shenkin <she...@still3.chem.columbia.edu> wrote:
>
> >Versatility is the enemy of comprehensibility.
>
> Definitely. And creativity is the enemy of obedience. Finding the right
> place between the two is a struggle.
>
> >Send him to a programming course, or buy him a good book, or have
> >him use F.
>
F won't work since he's got to use the
> same compiler as the rest of us and it's got to match libraries that we
> use.
Since an F program is also a Fortran 90 program he can do both. Use
the F compiler like a grammar checker. Run your code through it
during develoment to enforce what we like to call "good coding style"
and then use the normal compiler for production. Yes, you'll get
lots of messages about undefined library routines, but they can
be ignored.
Dick Hendrickson
Imagine1, Inc
[snip]
> Ken Plotkin
Walt Brainerd
Ken Plotkin (kplo...@access2.digex.net) wrote:
> I gave him my copy of Metcalf's "Effective Fortran 77". He used it as a
> coaster under his coffee cup. :-( F won't work since he's got to use the
> same compiler as the rest of us and it's got to match libraries that we
> use. I have told him to stick to F77 features. The cooler F90 and F95
> things and non-standard intrinsics do attract him like a moth to a flame.
As you say, they are "cooler", so why shouldn't they be attractive to
somebody that is trying to get some useful work done? As many here have
pointed out, there are a lot of advantages to using F90. Why artifically
cripple the effort?
--
Walt Brainerd wa...@fortran.com
Unicomp, Inc. +1-505-797-8989 797-3251 (fax)
2 San Rafael Ave NE, Suite C +1-500-Fortran (367-8726)
Albuquerque, NM 87122 USA http://www.fortran.com/fortran
Kenneth Plotkin
In article <343515...@worldnet.att.net>,
Dick Hendrickson <dick.hen...@worldnet.att.net> wrote:
>Since an F program is also a Fortran 90 program he can do both. Use
>the F compiler like a grammar checker. Run your code through it
>during develoment to enforce what we like to call "good coding style"
[snip]
We're using F77, so that wouldn't help. It's a good idea, though. I
already do something like that, using Lahey's F77 compiler to generate
cross-reference listings even though I use Microsoft Fortran to actually
build the programs.
I also make good use of Bob Moniot's "FTNCHECK" to find things that would
otherwise jump me in the middle of the night.
When the day comes that I need to learn the "Fortran 90 way", I expect
that I will use F to guide me.
Ken Plotkin
Roger Caffin
Walt Brainerd <wa...@swcp.com> wrote in article
<6143lh$5...@kitsune.swcp.com>...
> Ken Plotkin (kplo...@access2.digex.net) wrote:
> > I gave him my copy of Metcalf's "Effective Fortran 77". He used it as
a
> > coaster under his coffee cup. :-( F won't work since he's got to use
the
> > same compiler as the rest of us and it's got to match libraries that we
> > use. I have told him to stick to F77 features. The cooler F90 and F95
> > things and non-standard intrinsics do attract him like a moth to a
flame.
> As you say, they are "cooler", so why shouldn't they be attractive to
> somebody that is trying to get some useful work done? As many here have
> pointed out, there are a lot of advantages to using F90. Why artifically
> cripple the effort?
trying to say. The user was attracted to "cooler F90 and F95 things and
non-standard intrinsics", which is NOT the same as "more powerful things".
By way of explanation, let me mention a new programmer i had who had just
been introduced to "threads" (in C++). He thought they were wonderful.
Clearly a way of getting the computer to more things at once. (Ignore the
falacy there....) So he used lots of threads on a real-time system we had
under development. The trouble was, when a bug stopped one thread and
posted an error message, that message was quickly obscured by a window
reporting progress from another thread. The program slowly ground to a halt
of course, but finding which thread was at fault was hell! We ended up
rewriting the entire system in linear code. Coincidentally, once thread
management was not needed, it ran faster, but that's another matter.
So "cooler" may not mean "better". ESPECIALLY with young novice
programmers!
Cheers, Roger
--
Roger Caffin (Dr)
Director
Berrilee Consulting Services P/L
5 Charltons Ck Rd
Berrilee NSW 2159
Australia
All the usual disclaimers apply....
Jenn-Ching Luo
Roger Caffin <r.ca...@tpgi.com.au> wrote in article
> By way of explanation, let me mention a new programmer i had who had just
> been introduced to "threads" (in C++). He thought they were wonderful.
> Clearly a way of getting the computer to more things at once. (Ignore the
> falacy there....) So he used lots of threads on a real-time system we had
> under development. The trouble was, when a bug stopped one thread and
> posted an error message, that message was quickly obscured by a window
> reporting progress from another thread. The program slowly ground to a
halt
> of course, but finding which thread was at fault was hell! We ended up
> rewriting the entire system in linear code. Coincidentally, once thread
> management was not needed, it ran faster, but that's another matter.
I developed multi-threaded packages for numerical analysis in Fortran 77 &
90. In my opinion, F90 is better than F77. However, F90 standard is
insufficient for multi-threaded programming. Some extensions provided by
Fortran compilers are necessary; otherwise you need to develop your own
extensions in assembly. Those extensions are not portable to different
compilers. If F90 has a standard for the extensions, that would be better.
Multi-threaded applications are difficult in development. How to debug....
My experience is as:
(1) For homogeneous multi-tasking (each thread has the some subroutines or
functions), try one thread first. If getting bug, one thread is easy to
debug. If Ok, then try 2 threads, and debug. And, try more and more
threads. Homogeneous multi-tasking is important to numerical analysis, that
may easily distribute computation onto available processors so as to speed
up a computing.
(2) For heterogeneous multi-tasking (each thread has a particular set of
subroutines or functions): test each particular set first. When all the
sets are ok, it is the time to connect all the sets into a multi-tasking
system. Then, test and debug. Heterogeneous multi-tasking takes more time
in development, and is easy to get bugs.
Jenn-Ching Luo
****************************************************
*
* L...@Equation.com
* http://www.Equation.com/People/Luo.htm
*
****************************************************
Kenneth Plotkin
In article <01bcd0b8$9b77a280$9b9d1dcb@default>,
Roger Caffin <r.ca...@tpgi.com.au> wrote:
[snip]
>So "cooler" may not mean "better". ESPECIALLY with young novice
>programmers!
Exactly! Perhaps I should have said "meretricious" instead of "cooler".
BTW, a major consideration here is that he's not a programmer. Neither am
I. We're using Fortran to get some results out, so that the world will be
a better, safer place for sheep and military aircraft. There may be a lot
of very interesting things in F90, but anything interesting there is a
distraction.
Ken Plotkin
LC's No-Spam Newsreading account
On 3 Oct 1997, Kenneth Plotkin wrote:
> In article <343407...@still3.chem.columbia.edu>,
> Peter Shenkin <she...@still3.chem.columbia.edu> wrote:
>
> >Versatility is the enemy of comprehensibility.
> Definitely. And creativity is the enemy of obedience.
The reasonable man tries to adapt himself to the world.
The unreasonable man tries to adapt the world to himself.
Therefore all progress depends on the unreasonable man.
(That's G.B.Shaw, not me :-) )
> >Please give an example. Things like modules, automatic arrays, ALLOCATE
> >and array notation are very simple and very useful. It took me about
> >a day to learn to use them, at least in simple ways. Structures are
> >also pretty simple.
array notation is definitely useful (and was present in IDL, which is a
very powerful, although unfortunately commercial, data handling language
which is very fortranish and easy to use for us scientists (or even
engineers :-) ).
structures are also useful and were known to me from IDL and C, I wonder
why the committees deviated from the usual STRUCT.ELEMENT notation
and introduced the percent STRUCT%ELEMENT.
ALLOCATE can also be very useful, unfortunately f90 came too late when I had
my own set of c-jacket routines to handle this.
I'm not sure what you mean by automatic arrays.
Modules are the things which have so far kept me away from moving from
f77 to f90 (I've just read the Metcalf & Reid books), because I can't
understand them IN PRACTICE, i.e. whether they are dealt by the compiler
(like includes) or the linker (like shared libraries) and I'm *so* afraid
this will be implemented quite differently by different compilers, and
will give rise to confusion when porting code.
> In fact, when I think about the quantity of stuff I had to learn then, and
> the quantity of stuff in F90, I wonder if I'd have ever learned Fortran if
> I were doing it from scratch today.
Yes, I'm afraid the newest standard has made things more difficult
(the way C is) for an audience of scientist-programmers or
engineer-programmers.
Swietanowski Artur
Ralph Jay Frisbie wrote:
> I teach an introductory course at the local college. I avoid the
> complexities of F90 by using F. Sometimes I wonder if I'm doing my
> students any favors by presenting a reasonable, presentable, and
> modern language while hiding all of the warts and bloat of Fortran.
Yes! This is the way to go. 70% of F90's complexity is the result
of keeping on to the legacy language. I said it already in this
newsgroup and I'll say it again: F90 and F77 are two different
languages. Programs in F90 *should* be designed and written
differently that programs in F77.
The right approach to backward compatibility issue would be the
following:
a) require that a F90 processor has a separate F77 mode (which might
be just a call to an old F77 compiler that is only being kept
alive and not developed any more),
b) define interfacing rules for F90 calling F77 and the other way
around,
c) throw away all the unneeded F77 features from the language,
d) get on with the development of new, improved versions (F95,
F2000 etc.)
The step from F77 to F90 was to big to force vendors to make
a two-in-one langugage. On the contrary, F90 to F95 transition
would not require such a drastic change. In particular, if
the 4 point plan above was adopted, an F90 program would still
be a valid F95 program. It may not be now (if it contains F77
features that were dropped from F95).
Does this make sense to you?
Regards,
Artur Swietanowski.
----------------------------------------------------------------------
Artur Swietanowski mailto:swieta...@smc.univie.ac.at
Institut fuer Statistik, Operations Research und Computerverfahren,
Universitaet Wien, Universitaetsstr. 5, A-1010 Wien, Austria
tel. +43 (1) 407 63 55 - 120 fax +43 (1) 406 41 59
----------------------------------------------------------------------
Swietanowski Artur
LC's No-Spam Newsreading account wrote:
> f77 to f90 (I've just read the Metcalf & Reid books), because I can't
> understand them IN PRACTICE, i.e. whether they are dealt by the
> compiler (like includes) or the linker (like shared libraries) and
> I'm *so* afraid this will be implemented quite differently by
> different compilers, and will give rise to confusion when porting
> code.
A full explanation of how modules work would be too long. I can give
a short *practical* outline and one example how modules can work for
you if you want to obtain interface - implementation separation.
1) How it works in practice (user's perspective)
*NOTE* I'm not a compiler writer. What you read below is (I hope)
an educated guess (based on work with three and a half different
compilers).
A module is compiled and produces an object file. In the object file
you have all module-wide data and all code. A compiler often (always?)
produces another file with the interfaces only (for use when compiling
other source files that USE it).
The object file contains no repetitions and it's linked to an exec
once. No matter how many times you use a module (and it may be quite
a lot, the way it is designed) it's the *single* object file that's
included in the exec. (I wrote it twice, since you're not the only
person in the group that seems to be wary of MODULES).
This remains true regardless of whether or not you proceed as I
propose in the following.
2) How to separate interface and implementation: one possibility
*NOTE* I don't claim this is the only or the best way to go. I do it
that way.
a) When you create a derived type, put it in a separate module.
If you want to define specialized operations on this data type
you may (but don't have to) add them in the same module.
The cases in which you *have to* put derived data type definition
and operations on this type in the same module are rare (occur
when you use access restrictions).
b) Put the bulk of your code in separate external routines.
Put each function/subroutine (or a group of closely related
procedures) in one source file. Thus you create a number of
source files (not modules).
If you need to use a derived type in such a procedure, use the
appropriate module *in the procedure*.
c) Write a small number of modules with procedure interfaces only.
Divide your program into groups of more loosely related source
files (I mean code only). For each group write a single module
with the interfaces. Remember to put the USE statements in the
definitions of the interfaces when required.
I recommend a group of functions in the module, because you don't
want to create too many modules, that you'd later have to USE in
a hundred different places. Since the module would only contain
interfaces, any overheads related to it's object file size should
be negligible, or nonexistent.
d) Don't ever use global data (point only a bit related to the rest
of this posting).
! I mention it here, since I'm describing what to do with modules
! and how to do it. The language allows creation and use of
! module-wide data. It's just that every time I used some global
! data, I later had to rewrite it in the way outlined below.
Create a dervied type instead and always pass an object of this
type to the procedures which would require the global data.
This way you avoid problems when in future you'd want to have two
(or more) instances of the same, say, optimizer running.
Example ====================================================
a) module with a derived type definition
MODULE x_type
TYPE(x)
INTEGER :: n, n_max
REAL, DIMENSION(:), POINTER :: r
END TYPE(x)
END MODULE x_type
b) a file with an external subroutine
SUBROUTINE increment_x( x_object )
USE x_type
TYPE(x) :: x_object
! the rest of the code
END SUBROUTINE increment_x
c) a module with interfaces to some external procedures
MODULE some_procs
INTERFACE
SUBROUTINE increment_x( x_object )
USE x_type
TYPE(x) :: x_object
END SUBROUTINE increment_x
END INTERFACE
! Other interfaces
END MODULE some_procs
End of the example============================================
Hope this helps. It took too much typing if it doesn't.
Regards,
Artur Swietanowski
michael
In article <3438C0...@smc.univie.ac.at>, swieta...@smc.univie.ac.at
says...
>Artur Swietanowski mailto:swieta...@smc.univie.ac.at
>Institut fuer Statistik, Operations Research und Computerverfahren,
>Universitaet Wien, Universitaetsstr. 5, A-1010 Wien, Austria
>tel. +43 (1) 407 63 55 - 120 fax +43 (1) 406 41 59
>----------------------------------------------------------------------
No, not entirely. With a large base of subroutine libraries depeloped
over the years, I would be extremely reluctant to change if I could not do
it gradually.
And as for 'throwing away all the unneeded F77 features from the language'
who decides which they are. Some purist might be insane enough to remove
GOTO.
Michael
fair...@sldb4.slac.stanford.edu
In article <Pine.OSF.3.95.971006...@poseidon.ifctr.mi.cnr.it>,
LC's No-Spam Newsreading account <nos...@ifctr.mi.cnr.it> writes:
[...]
> why the committees deviated from the usual STRUCT.ELEMENT notation
> and introduced the percent STRUCT%ELEMENT.
Very simply because it causes/allows for ambiguous constuctions.
Consider (using VMS STRUCTUREs and RECORDs) the following:
STRUCTURE /FOO/
LOGICAL B,C
END STRUCTURE
STRUCTURE /BAR/
RECORD /FOO/ EQ,LT,GT
END STRUCTURE
RECORD /BAR/ X,Y, B,C
...
IF (X.EQ.B .OR. Y.LT.C) THEN
...
ENDIF
Since there are no reserved words in Fortran (which I think is a
Good Thing(tm), but others would disagree), the above construction
is highly ambiguous. Are we doing a logical-or between two record
elements, X.EQ.B and Y.LT.C, or are we asking that the entire record
X be compared to the record B, and similarly the record Y be
compared to record C?
FWIW, the VMS Fortran documentation has always warned of
unintended ambiguities of this sort and discouraged their use. But
as much as I dislike the _appearance_ of the percent-sign element
delimiter in F90, it's clear to me that the committee made the Right
Choice(tm) in _not_ using the period.
-Ken
--
Kenneth H. Fairfield | Internet: Fair...@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 46 | DECnet: 45537::FAIRFIELD (45537=SLACVX)
Stanford, CA 94309 | Voice: 650-926-2924 FAX: 650-926-3515
-------------------------------------------------------------------------
These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
Ralph Jay Frisbie
Kenneth Plotkin <kplo...@access1.digex.net> wrote in article
<610qq3$n...@access1.digex.net>...
> In article <343356...@vcnet.com>,
> Ralph Jay Frisbie <rfri...@vcnet.com> wrote:
>
> > Yes, because it is OPTIONAL. Hence, an algorithm which needs them,
>
> Optional only if you work by yourself or in a very tightly controlled
> environment. A huge amount of Fortran is written by one engineer, then
> downstream another engineer inherits the code and has to do something
with
> it. So you eventually do need to learn everything, like it or not.
>
> Loading Fortran up with all of this stuff also steepens the learning
> curve. I've got a young physicist working for me who is driving me nuts.
> He's learning Fortran, and he seems to be hell-bent on using every odd
> trick he can find. He's stumbling over the basics, and confusing things
> by even worse trying to be fancy. Part of the problem is that he's just
> got an exploring attitude to whatever he does, and part of it is that
he's
> overwhelmed with all of the stuff that's now in Fortran.
>
> I see a lot of questions in this NG about how to use some of the more
> esoteric features of F90. They don't seem to be from real programmers;
> probably graduate students or maybe young engineers. I can't figure out
> why anybody would need to do some of the things they are trying. I feel
> great sympathy for the next engineer or graduate student who comes along
> and tries to continue.
>
> Ken Plotkin
>
I agree that I wish our world had not become complex. I do not
see how we can create a language to enable a user to use the power of
a modern computer without also adding complexity.
I too hunger for the age of Benjamin Franklin, when an educated
man could truly know all worth knowing - when the world's knowledge
was containable in one reasonable library.
Just think how much easier it was to learn _____ (fill in your
favorite field) in the 19th century!. Calculations by log tables with
pencils. I am not meaing to belittle, but to emphasize that the inherent
complexity of our total existance has qualitatively increased.
My first Fortran course was a two hour lecture by an IBM salesman
in 1960. The engineer's manual was about 20 pages. It was certainly
easier to learn and far less confusing, and no confusing options on
if , just IF( X ) 10,20,30
I too am chagrinned by the bloat of F90 - yet I question how to
avoid the bloat while maintaining the conflicting requirements of
backwards compatibility and modernization and extensions of capablity. the
most extreme bloat I've seen is DEC's DVF 5.0 I feal sorry for them,
maintaining a backwards compatibility with all the extensions DEC added
over the years and then integrating that with F90 standard.
I teach an introductory course at the local college. I avoid the
complexities of F90 by using F. Sometimes I wonder if I'm doing my
students any favors by presenting a reasonable, presentable, and modern
language while hiding all of the warts and bloat of Fortran. My personal
decision was to give the student a good background, keep screaming
structure at them, and pray that on the job training will encourage and
finish them. Of course, I know most will go off ot University and probably
get screwed up by the academicians.
ralph frisbie
rfri...@vcnet.com
N8TM
Standards committees already have made up an official obsolescence list, and
compiler vendors in some cases have removed obsolescent constructs from
eligibility for code optimization: e.g. ASSIGNED GOTO, arithmetic IF, both of
which have demonstrated superior alternatives at least since f77.
Tim
Christopher Mahmood
[big snip]
: I've got him working a a project that needs modification to a fairly small
: program - about 100 lines. He's using the program to help make sense of
: some data that somebody else collected. I critique what he does as he
: does it, and also critique what I should have done better in my part
: before he arrived. Sometimes I leave him alone til he gets confused.
: Depends on my mood and what I think will help him learn. Sometimes I
: start sounding like my mother. :-(
no, you sound like a good advisor...i'd give anything to have advisor
sit down with me like that.
-ckm
Paddy O'Brien
This is an area where I fervently disagree with Ken. We both use the
same operating system, so I might refer to it on a few occassions --
Digital OpenVMS, and I find their terminology "structure" easier than
"derived type".
Our team has used Digital structures for many years with no problems.
Quite frankly, we believe that anyone who is idiotic enough to use EQ,
GT, etc. as elements of a structure deserve all they get. Yes, there
will always be idiots who will find a way that causes conflict in the
compiler and submit a "bug" report. For this reason, I accept Ken's
comment that Digital "has always warned of unintended ambiguities",
though I have not been able to find this in the documentation
(reference please, Ken).
The % in a derived type is ugly on paper/screen, and also difficult to
say when we are peer checking our code, which we do at team meetings.
"Dot" is so much easier to say than "percent", although we have tried
using just "per", also with difficulty.
Other languages that have "dot" structures, can avoid this ambiguity
because of symbolic rather than mnemonic conditional notation.
The F90 standards committee had quite an easy let-out:: "dot"
structures/derived types cannot be used in a condition unless symbolic
notation is used, hence "==" not ".EQ."
This may seem to fly in the face of the no-keyword origins of Fortran,
but I see this as little different from the strictures that in
free-format spaces can be relevant where in fixed format they are not.
Regards, Paddy
Blah
Blah
Blah
Blah
Blah
Stupid Bill Gates rules about more included text than original
Blah
Blah
Blah
Blah
Blah
Sorry folks for wasting bandwidth, but what Bill Gates decrees must be
so
blah
blah
blah
Hey, case sensitive blah's
Jeeze I hope this is enough crap.
Craig Burley
paddy.o'br...@transgrid.nswgovgrid.telememo.au (Paddy O'Brien) writes:
> The F90 standards committee had quite an easy let-out:: "dot"
> structures/derived types cannot be used in a condition unless symbolic
> notation is used, hence "==" not ".EQ."
How would this "easy" way handle combining user-defined operators
(for example, .FOO. and .BAR.) with user-defined member names
(for example, FOO and BAR)? Or would it just forbid entirely the
user of user-defined operators in combination with user-defined types
(aka Digital-style STRUCTUREs)?
> This may seem to fly in the face of the no-keyword origins of Fortran,
> but I see this as little different from the strictures that in
> free-format spaces can be relevant where in fixed format they are not.
It's quite different. The latter strictures introduce (AFAIK) *no*
new "reserved" names in Fortran, in the sense that the user never has
to worry about avoiding *any* particular names for variables (except,
in one weird case, "END", the case being "END" with the next line
continuing with "= ...").
BTW, I agree that using `%' is ugly. I've already pretty much decided
that "the" new language I create someday will simply use `/' to
designate selection. Pretty much everyone is already used to that,
thanks to the Web, and there's too much disagreement about what
division means (in cases such as when two integer variables are
involved) to devote such a single, useful character to a particular
meaning of division. I'd rather use `%' to mean what it already does
mean in polite society -- "percent". :)
But, Fortran 90 didn't have much choice. IMO if they "could" have
used `.' given a bunch of non-Fortran-like restrictions, they might
as well have used `/' instead given, probably, fewer non-Fortran-like
restrictions. At least `%' has a slash in it somewhere!
All of these are better, IMO, than `>', which is what PRIMOS used
for `/'.
--
"Practice random senselessness and act kind of beautiful."
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
N8TM
That's a revelation! Craig is a veteran of Primos?
Erwin Dieterich
Help us unknowing souls: what is Primos and what can I
learn from Craig having something to do with it?
- Erwin
N8TM
Primos was a series of operating systems for the Prime minicomputers, which
started out as 16 bitters. Early versions of Primos were written in slightly
extended FORTRAN 66 (so they said) and later versions in PL/I. Floating point
arithmetic was done in double precision width accumulators (2 of them in the
later models). Prime was a leader in supporting COBOL and had brief market
success on that basis.
Tim
Craig Burley
n8...@aol.com (N8TM) writes:
> That's a revelation! Craig is a veteran of Primos?
Yup. My first "real" job was as a software engineer at Prime,
working on FUTIL, then CX (the old batch subsystem, which I made
handle multiple jobs and be more robust by not dropping jobs through
the cracks ;-), SPOOL (for which I designed, and someone else
implemented, a scheme to cope with network-wide printing), BATCH
(which I helped design and did implement myself), QPAKS (partly
my design, all my implementation, and, thankfully, did not really
see the light of day, due to other people finally agreeing with
my objections to the whole approach of using publically-writable
shared memory to schedule file transfer, batch jobs, and print
requests -- I'd proposed a client-server approach that higher-level
tech types rejected, so I guess I had the last laugh ;-), and some
work on PRIMOS itself, of course.
Then I left and came back as a tech writer, writing, among other
things, "Advanced Programmer's Guide", a 4-volume set (though
another writer wrote the introductory material on the filesystem,
IIRC, under my direction), which was pretty much my "one big opus".
It was mostly a fun and interesting place to work, and, yes,
the OS and most utilities were in FORTRAN 66 (Prime's FTN) and
assembly, with PL/P being used for a while, then migrating to
PL1/G, and SPL, all of these being subsets of PL/1, though PL/P
lasted longest in PRIMOS itself, I believe.
Before Prime, most of my experience was on PDP-10's, -8's, and
the like, systems like TOPS-10 and MIT ITS, plus ARPANET. Fortran
was something I wanted to avoid for a long time, but had to cope
with at Prime. I didn't come to really respect it until I left
Prime for Numerix to learn more about what was done to make
computer programs go *real* fast, and began to discover how
important language design can be in making such things happen.
But, ever since I was 15, I wanted to have/write a Fortran front
end to at least make coping with Fortran somewhat easier (say,
renumbering statement labels, or finding all occurrences of
variable names), so when I was asked to write a Fortran front
end for GNU, it didn't seem like such a weird request.
That's how I got into doing g77.