Re: Learning Fortran
- From: Rune Allnor <allnor@xxxxxxxxxxxx>
- Date: Tue, 25 May 2010 05:12:41 -0700 (PDT)
On 25 Mai, 12:50, "Baalzamon " <baalzamon_mori...@xxxxxxxxx> wrote:
Howdy there, once again. With regards to a few of the points brought up by various people.
1) The main code has several subroutine calls and by my quick flowchart-check the calls go five deep at a max. That is to say once calls another, which calls another, which calls another etc.
These are the key points one would look for in a procedural language:
Isolate what goes on inside each subroutine (the same as 'function'
in matlab), make sure one understands what each function is supposed
to do, then test it independently.
Once you have done all that, you can be *reasonably* sure (but by no
means certain) you have a good building block for what follows.
2) There are goto jumps, including the much tricksome (for a complete newcomer such as myself) 'computed?' goto.
I have never heard of it before, and there is no reason why you
should have to deal with it. This was obsolete 40 years ago.
3) The maths behind the routine are currently beyond me. Though largely this wouldn't be a problem if the source code was filled with comments explaining what is the point of lines x to y etc.
Exactly. The author likely used all kinds of tricks *both* with
the implementation *and* the algorithm. The job is hard enough
if one only wants to derive the algorithm - there is no need to
have to deal with 40-year-old tricks no one have had to deal
with after Neal Armstrong walked the moon.
Which is why you would want to derive the algorithm from scratch
and record the algorithm.
As for comments, that's the main problem with computer
programming: The comments and the code are two different
accounts for the same algorithm. The problem is to keep
them synced up: It is enough work to maintain the *code*,
that makes the program do its job. Keeping an independent
comments base updated effectively doubles the amount of
work required, eventually causing that code and comments
slip out of sync.
The trend these days is to write lots of small, trivial
functions, that do very little and that have descriptive
names that explain to the human reader what they do. Some
program I wrote a few years back have a main routine that
goes something like [*]:
function coeffs = computeIIRfilterCoefficients(spec)
if (specificationIsValid(spec))
Nspec = normalizeSpec(spec);
PWSpec = preWarpSpec(Nspec);
Order = FindOrder(PWspec);
SDcoeffs = ComputeSDomainCoeffs(PWspec,Order);
ZDcoeffs = BilinearTransform(SDcoeffs);
coeffs = DenormalizeFilter(ZDcoeffs,spec);
end
Somebody who knows a little about the filter design procedure
in question immediately understands what is going on here,
merely by reading the names of the subroutines. Each of the
functions contain similarly self-documenting code, and this
goes on until the contents of a function can be described
by a single formula.
[*] (I wrote C++ rather than matlab, as matlab has way to
high run-time penalty at function calls for this style
of coding. C++ also allows me, the coder, to delegate
a number of tests and conditionals to the compiler.
For instance, there are mo tests in the code snippet
above to determine if the filter in question is a
low pass, high pass or other filter. This information
is encoded in the type of the filter specification,
and it is the compiler's responsibility, not the coder's,
to ensure that the low-pass versions of the routines are
called when a low-pass spec is issued to the routine.)
Coding in this way might seem a bit demanding up front, as
one clearly needs to understand *exactly* what is going on
and what the program is going to do, to pull off something
like this.
But on the other hand, only a fool would think one can get a
working program up and running *without* that kind of
understanding of the problem domain....
Er there were some more points, however, I got lost during the reading of this topic.
Currently I have translated some of it...until i found that I had to set x=y where y is not established until a subroutine call later on.
Which means that either
- You have missed something.
- The code you use works with relies on uninitialized variables
- The code you work with relies on stuff going on one or more levels
above the one you have access to (that y belongs in the scope of
the program that calls the routine you work with)
- The variable y is implicitly initialized by the compiler.
You can *hope* for the latter, but don't rely on it.
Some specfic questions:
excerpt from code
if (a .eq. 1) goto 85
Now does this mean that if a does not equal 1 then execute code immeadiately after the if statement...
Yes.
then when we arrive at '85' do we ignore it or execture also?
Yes, unless a branch has been reached in between.
Go to (15,25), L
DOes this mean depending upon the values of 'L' jump to 15 or 25? If so Is the argument governed by 'L' in ascending order? Such that, say 'L' could be 1 or 2 then if L=1 go to 15 and if L=2 go to 25?
Who knows? These are the kinds of things that would be handled
by literal if-then-else tests or case-switch tests in C and later
languages. The main difference is that literal statements
are immediately understandable to the human reader of the code.
They don't mean much to the compiler, as it will be able to translate
the literal statements more or less 1:1 to gibberish like the above.
The point is that you, the user, should have to deal with *what*
the routine does, not *how* it does it. This lack of focus on the
human user is *the* main drawback of fortran (along with that stuff
that is trivial in later languages is at least cumbersome, maybe
even difficult, to pull off with fortran) and is the main reason
why you would want to have as little as possible to do with it.
Depending on where you got the code from, find any companion
reports, published articles, or other documents, and use them
to derive the algorithm from scratch.
Rune
.
- References:
- Learning Fortran
- From: Baalzamon
- Re: Learning Fortran
- From: Baalzamon
- Learning Fortran
- Prev by Date: Re: Using ginput or related fuction to "connect the dots"
- Next by Date: Re: Change axes of ellipsoid
- Previous by thread: Re: Learning Fortran
- Next by thread: Re: Learning Fortran
- Index(es):
Relevant Pages
|
