Fortran - Why do you still use Fortran?

Author

Why do you still use Fortran?

AN O'Nymous

2005-12-09, 7:18 pm

When I first graduated, I was quite unsettled to learn that C/C++ was
the lingua franca in most of the engineering companies I applied to,
and that Fortran tended to be used in niche applications.

My undergraduate education only encompassed Fortran and although I
could have put effort into learning C/C++, I thought (and still think)
that spending time learning another language would turn me into a jack
of all trades, but master of none.

So...why do you still use Fortran?

Why do these niche applications (such as the algorithms running on the
Earth Simulator) use Fortran?

As an undergrad, we were told that Fortran was more efficient for
math-intensive algorithms. Is this true? Why is this the case and what
sources cite this to be so?

Do you suggest that I at least pick up some basic C/C++? If so, where
should I start?

Thanks.

Ronald Benedik

2005-12-09, 7:18 pm

"AN O'Nymous" <a_n_onymous80@yahoo.co.uk> schrieb im Newsbeitrag
news:1134138453.391502.214850@g44g2000cwa.googlegroups.com...

> When I first graduated, I was quite unsettled to learn that C/C++ was
> the lingua franca in most of the engineering companies I applied to,
> and that Fortran tended to be used in niche applications.

Fortran was one of the first languages available for computers.

> My undergraduate education only encompassed Fortran and although I
> could have put effort into learning C/C++, I thought (and still think)
> that spending time learning another language would turn me into a jack
> of all trades, but master of none.
>
> So...why do you still use Fortran?

It is suitable for math intensive applications. Comparing it to C++ is
unfair
because there is no object oriented Programming in the current Fortran
standards.

> Why do these niche applications (such as the algorithms running on the
> Earth Simulator) use Fortran?

Because there's HPF (High Performance Fortran) that can parallize
Fortran Programms just by adding $HPF comments.

> As an undergrad, we were told that Fortran was more efficient for
> math-intensive algorithms. Is this true? Why is this the case and what
> sources cite this to be so?

Fortran has a different array indexing than C. That account s for most of
the
speed increase. sometimes Fortran is referred to as powerful as Assembler
language.

> Do you suggest that I at least pick up some basic C/C++? If so, where
> should I start?

C is suitable for system programming Fortran is not. I recommend
Herbert schildts book "teach yourself C" for introduction to C
programming.

Tim Prince

2005-12-09, 7:18 pm

Ronald Benedik wrote:
> "AN O'Nymous" <a_n_onymous80@yahoo.co.uk> schrieb im Newsbeitrag
> news:1134138453.391502.214850@g44g2000cwa.googlegroups.com...
>

>
>
>
> C is suitable for system programming Fortran is not. I recommend
> Herbert schildts book "teach yourself C" for introduction to C
> programming.
>
>
The consensus on comp.lang.C (an excellent resource) heartily
disrecommends his books.

Ronald Benedik

2005-12-09, 7:18 pm

"Tim Prince" <tprince@nospamcomputer.org> schrieb im Newsbeitrag
news:6rhmf.29032$7h7.2459@newssvr21.news.prodigy.com...

> The consensus on comp.lang.C (an excellent resource) heartily
> disrecommends his books.

For what reason? Too few progrmming examples?

Gareth Owen

2005-12-09, 7:18 pm

"Ronald Benedik" <rbenedik@fsmat.htu.tuwien.ac.at> writes:

> "Tim Prince" <tprince@nospamcomputer.org> schrieb im Newsbeitrag
> news:6rhmf.29032$7h7.2459@newssvr21.news.prodigy.com...
>
>
> For what reason? Too few progrmming examples?

Plentiful programming examples, too few of which are correct.

Ronald Benedik

2005-12-09, 7:18 pm

"Gareth Owen" <usenet@gwowen.freeserve.co.uk> schrieb im Newsbeitrag
news:r5i3bl2mg68.fsf@gill.maths.keele.ac.uk...

> Plentiful programming examples, too few of which are correct.

But if you compare it to K&R, K&R gives too few information.

Stewart Gordon

2005-12-09, 7:18 pm

Ronald Benedik wrote:
> "AN O'Nymous" <a_n_onymous80@yahoo.co.uk> schrieb im Newsbeitrag
> news:1134138453.391502.214850@g44g2000cwa.googlegroups.com...
<snip>

Because my department hasn't moved on as yet.
[color=darkred]
> It is suitable for math intensive applications. Comparing it to C++
> is unfair because there is no object oriented Programming in the
> current Fortran standards.

Maybe once D takes off....

http://www.digitalmars.com/d/

>
> Because there's HPF (High Performance Fortran) that can parallize
> Fortran Programms just by adding $HPF comments.

But why did somebody decide to write HPF and not HPC or something else?

>
> Fortran has a different array indexing than C. That account s for
> most of the speed increase.

How do you work that out? Surely if either is more efficient then it's
C's hard-wired zero-based indexing?

> sometimes Fortran is referred to as powerful as Assembler language.
<snip>

As in ... Turing complete?

Stewart.

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.

Ronald Benedik

2005-12-09, 7:18 pm

"Stewart Gordon" <smjg_1998@yahoo.com> schrieb im Newsbeitrag
news:dncaaa$1f9$1@sun-cc204.lut.ac.uk...

>
> But why did somebody decide to write HPF and not HPC or something else?

There is already a HPC from the Russian Academy of Sciences. HPF increases
the productivity of a experienced MPI programmer.

>
> How do you work that out? Surely if either is more efficient then it's
> C's hard-wired zero-based indexing?

Numerical Linear Algebra profits most of the different array indexing
( I meant array memory allocation).

> <snip>
>
> As in ... Turing complete?

Fortran is Turing complete. the refernce accounts only for math
applications.

David

2005-12-09, 7:18 pm

"AN O'Nymous" <a_n_onymous80@yahoo.co.uk> wrote in message
news:1134138453.391502.214850@g44g2000cwa.googlegroups.com...
> When I first graduated, I was quite unsettled to learn that C/C++ was
> the lingua franca in most of the engineering companies I applied to,
> and that Fortran tended to be used in niche applications.
>
> My undergraduate education only encompassed Fortran and although I
> could have put effort into learning C/C++, I thought (and still think)
> that spending time learning another language would turn me into a jack
> of all trades, but master of none.
>
> So...why do you still use Fortran?

Languages come and go. C has been around for a long time but it is best for
short routines that interact with hardware. For developing numerical
applications the choice may come down to Fortran or chasing the latest fad
language. It has been my experience -- having spent much time chasing the
latest fad -- that the small advantages gained using the latest languages
are usually not worth the trouble it takes to learn them.

If the purpose of the code is to interact with a PC running a Microsoft
operating system than using a Microsoft supported language may make that
easier. This is especially true if the code is not expected to have value
for a long time. If the goal is to find a solution to a numerically
intensive engineering problem (that does not interact with hardware),
especially if the code may be used for many years to come, Fortran is a good
choice.

>
> Why do these niche applications (such as the algorithms running on the
> Earth Simulator) use Fortran?
>

This may have something to do with the numerics being more important than
the user interface or other IO which is machine dependent.

> As an undergrad, we were told that Fortran was more efficient for
> math-intensive algorithms. Is this true? Why is this the case and what
> sources cite this to be so?

Fortran is designed to be efficient. It is possible to write C as efficient
as Fortran but only if you really know C well. Fortran is efficient "by
default".

>
> Do you suggest that I at least pick up some basic C/C++? If so, where
> should I start?
>
Why not Java, Visual Basic or what ever comes next? C/C++ has many features
that make it needlessly complex and error proned unles a programmer really
knows what they are doing. It is not a language for the casual programmer.
Both Java and VB are easier to do simple things with.
>
> Thanks.
>

David

2005-12-09, 7:18 pm

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
news:dncaaa$1f9$1@sun-cc204.lut.ac.uk...
> Ronald Benedik wrote:
> <snip>
>
> Because my department hasn't moved on as yet.

Your department may not know which language to choose. Is it Java, C++,
Basic?

>
>
> Maybe once D takes off....
>
> http://www.digitalmars.com/d/
>
>
> But why did somebody decide to write HPF and not HPC or something else?
>
>
> How do you work that out? Surely if either is more efficient then it's
> C's hard-wired zero-based indexing?

I think it is the multidimensional arrays that are the issue.

>
> <snip>
>
> As in ... Turing complete?
>
> Stewart.
>
> --
> -----BEGIN GEEK CODE BLOCK-----
> Version: 3.1
> GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
> PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
> ------END GEEK CODE BLOCK------
>
> My e-mail is valid but not my primary mailbox. Please keep replies on
> the 'group where everyone may benefit.

James Giles

2005-12-09, 7:18 pm

Ronald Benedik wrote:
....
> C is suitable for system programming Fortran is not. I recommend
> Herbert schildts book "teach yourself C" for introduction to C
> programming.

Well, I've done system programming in a variety of languages,
including C and (a suitably extended) Fortran. I've never found
C to be particularly well suited to the job. Fortran isn't either,
without certain extensions (and the F90+ does not include
those extensions, nor make the language better suited to the
purpose).

The operating system is the one component of your computer
environment that everyone *must* use. It is, therefore, vital
that it be the most reliably built component of your environment.
Using C mitigates against that.

--
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

Greg Lindahl

2005-12-09, 7:18 pm

In article <4399a7c0$0$22262$91cee783@newsreader02.highway.telekom.at>,
Ronald Benedik <rbenedik@fsmat.htu.tuwien.ac.at> wrote:

>But if you compare it to K&R, K&R gives too few information.

People are different. K&R has plenty of information for some people.

Likewise, the right Fortran book depends on whether Fortran is the
first programming language of the reader, or if the reader has
natural talent...

-- greg

David Flower

2005-12-09, 7:18 pm

David wrote:[color=darkred]
> "AN O'Nymous" <a_n_onymous80@yahoo.co.uk> wrote in message
> news:1134138453.391502.214850@g44g2000cwa.googlegroups.com...
>
> Languages come and go. C has been around for a long time but it is best for
> short routines that interact with hardware. For developing numerical
> applications the choice may come down to Fortran or chasing the latest fad
> language. It has been my experience -- having spent much time chasing the
> latest fad -- that the small advantages gained using the latest languages
> are usually not worth the trouble it takes to learn them.
>
> If the purpose of the code is to interact with a PC running a Microsoft
> operating system than using a Microsoft supported language may make that
> easier. This is especially true if the code is not expected to have value
> for a long time. If the goal is to find a solution to a numerically
> intensive engineering problem (that does not interact with hardware),
> especially if the code may be used for many years to come, Fortran is a good
> choice.
>
>
> This may have something to do with the numerics being more important than
> the user interface or other IO which is machine dependent.
>
>
> Fortran is designed to be efficient. It is possible to write C as efficient
> as Fortran but only if you really know C well. Fortran is efficient "by
> default".
>
> Why not Java, Visual Basic or what ever comes next? C/C++ has many features
> that make it needlessly complex and error proned unles a programmer really
> knows what they are doing. It is not a language for the casual programmer.
> Both Java and VB are easier to do simple things with.

FORTRAN has been around since 1957, so there is a lot of source code
around, some of which actually works! The old engineering maxim 'If it
works, don't fix it applies'

Dave Flower

Greg Lindahl

2005-12-09, 7:18 pm

In article <4399a020$0$15669$91cee783@newsreader01.highway.telekom.at>,
Ronald Benedik <rbenedik@fsmat.htu.tuwien.ac.at> wrote:

>
>Because there's HPF (High Performance Fortran) that can parallize
>Fortran Programms just by adding $HPF comments.

Only a modest fraction of Earth Simulator apps use HPF. HPF is
considered a dead-end by most people.

-- greg

Greg Lindahl

2005-12-09, 7:18 pm

In article <1134138453.391502.214850@g44g2000cwa.googlegroups.com>,
AN O'Nymous <a_n_onymous80@yahoo.co.uk> wrote:

>Do you suggest that I at least pick up some basic C/C++? If so, where
>should I start?

It is always good to know multiple computer languages. I always look
for that in a job applicant.

-- greg

M. Gross

2005-12-09, 7:18 pm

I used some programming languages sinde the "Programmkalkuell" of Zuse,
Cobol, Algol (different versions), Fortran, Pascal (including Delpi. which
is still my favoriteI). But when it comes to numerical problems I could not
find a better language than Fortran 95 with its object oriented features. So
I hope that this language will not disappear as long as I will live.

Having some experience with process control by process oriented operating
computers I think that even under such special operating systems Fortran can
be a good language when it comes to processing signals.

So I can't think that Fortran is a language that is useless.

Manfred G.

"AN O'Nymous" <a_n_onymous80@yahoo.co.uk> schrieb im Newsbeitrag
news:1134138453.391502.214850@g44g2000cwa.googlegroups.com...
> When I first graduated, I was quite unsettled to learn that C/C++ was
> the lingua franca in most of the engineering companies I applied to,
> and that Fortran tended to be used in niche applications.
>
> My undergraduate education only encompassed Fortran and although I
> could have put effort into learning C/C++, I thought (and still think)
> that spending time learning another language would turn me into a jack
> of all trades, but master of none.
>
> So...why do you still use Fortran?
>
> Why do these niche applications (such as the algorithms running on the
> Earth Simulator) use Fortran?
>
> As an undergrad, we were told that Fortran was more efficient for
> math-intensive algorithms. Is this true? Why is this the case and what
> sources cite this to be so?
>
> Do you suggest that I at least pick up some basic C/C++? If so, where
> should I start?
>
> Thanks.

Rich Townsend

2005-12-09, 7:18 pm

Ronald Benedik wrote:
> "AN O'Nymous" <a_n_onymous80@yahoo.co.uk> schrieb im Newsbeitrag
> news:1134138453.391502.214850@g44g2000cwa.googlegroups.com...
>
>
>
>
> Fortran was one of the first languages available for computers.
>
>
>
>
> It is suitable for math intensive applications. Comparing it to C++ is
> unfair
> because there is no object oriented Programming in the current Fortran
> standards.
>
>
>
>
> Because there's HPF (High Performance Fortran) that can parallize
> Fortran Programms just by adding $HPF comments.

It seems that HPF to a large extent is dead.

>
>
>
>
> Fortran has a different array indexing than C. That account s for most of
> the
> speed increase. sometimes Fortran is referred to as powerful as Assembler
> language.

I think you are

here. Sure, for a multidimensional array, Fortran and C
access memory with a different index scheme (column major vs row major -- or the
other way around). However, while this is important to consider when writing
code that doesn't hammer the cache, it doesn't lead to a speed advantage of
Fortran over C *per se*.

You may instead be referring to the fact that aliasing is prohibited in many
cases by Fortran, whereas it is very much a part of traditional C. Aliasing is a
major cause of optimization bottlenecks. Note that C99 adds the 'restrict'
keyword to mitigate aliasing issues, but I've yet to see code that uses it.

cheers,

Rich

David

2005-12-09, 7:18 pm

> Because there's HPF (High Performance Fortran) that can parallize
> Fortran Programms just by adding $HPF comments.

What is the PURE keyword in Fortran 95 for? Won't PURE standardize and
replace $HPF?

Greg Lindahl

2005-12-09, 7:18 pm

In article <6snmf.38919$_k3.17038@dukeread01>,
David <Contributor@AdsorptionProcessModeling.com> wrote:

>What is the PURE keyword in Fortran 95 for? Won't PURE standardize and
>replace $HPF?

That's only a small part of what HPF tried to do.

-- greg

Dan Nagle

2005-12-09, 7:18 pm

Hello,

Greg Lindahl wrote:
> In article <6snmf.38919$_k3.17038@dukeread01>,
> David <Contributor@AdsorptionProcessModeling.com> wrote:
>
>
>
>
> That's only a small part of what HPF tried to do.

Pure simply means that a procedure has no side-effects.
A pure declaration allowed parallel execution.

Most of HPF is aimed towards aligning arrays distributed
across several processors.

The result was, in too many cases anyway, hard to understand.
The number of applications which fit well into the HPF model
proved to be too few, and there never was dedicated
support from compiler vendors.

Today, it's considered yet-another-valiant-effort
at high-level parallelism that didn't quite work.

--
Cheers!

Dan Nagle
Purple Sage Computing Solutions, Inc.

Richard Maine

2005-12-09, 7:18 pm

Dan Nagle <dannagle@verizon.net> wrote:

> Pure simply means that a procedure has no side-effects.
> A pure declaration allowed parallel execution.

among other things. PURE also is needed for other things where side
effects would be problematic. One notable example is specification
functions.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain

Brooks Moses

2005-12-09, 7:18 pm

AN O'Nymous wrote:
> When I first graduated, I was quite unsettled to learn that C/C++ was
> the lingua franca in most of the engineering companies I applied to,
> and that Fortran tended to be used in niche applications.
>
> My undergraduate education only encompassed Fortran and although I
> could have put effort into learning C/C++, I thought (and still think)
> that spending time learning another language would turn me into a jack
> of all trades, but master of none.

I think that's an unwise idea. Spending the time to learn another
language (particularly one that's conceptually different from what you
are used to, like C++) will introduce you to other ideas about how
programs can be structured. This will give you a broader toolset that
you can then use when designing programs to be written in Fortran.

Because of that sort of thing, I believe that learning C++ has improved
my Fortran programming skills. A lot of the concepts around "object
oriented" code are very useful in many programming applications -- and
many of the concepts are quite usable in Fortran programming, but the
language doesn't happen to guide the user in writing that way, so it's
not something I would have been likely to learn without learning C++ or
something similar.

The only thing that you might lose, in my experience, in learning other
languages rather than spending that time on Fortran, is that you might
not have the sort of understanding that allows you to tell me the
difference between the MOD() and MODULO() intrinsic functions without
looking it up. Except in rare conditions, I don't think that's a
significant loss. The fundamental skill is not "Fortran programming",
but "programming", and any time spent programming in any language
improves that skill, particularly if you're doing something new.

> So...why do you still use Fortran?

Because its language features match well to the set of things that I
want to write, and thereby make it easier for me to write the programs
that I'm writing.

Specifically, Fortran's core language is designed to make it very easy
to deal with multidimensional arrays. They are easy to declare, easy to
allocate without requiring one to worry about memory leaks, easy to pass
around, and easy to select subsections of. It's also easy to do
whole-array operations such as setting all the elements to a uniform
value or to a function of another array.

To get anything approximating that in C++, I would need to use some sort
of library file, and then I would need to worry about whether that
library was present everywhere I wanted to use my code, and so forth;
with Fortran, it's part of the language. More significantly, I probably
would not use the same C++ array library that someone else uses, and
that makes it harder for me to use their code in mine, or to contribute
to their project.

Beyond that, Fortran has a number of other nice features that I find
useful -- intent() declarations, for instance. The Fortran I/O system
is very nice for writing purpose-specific data files; it doesn't require
much work at all to get something working.

> Why do these niche applications (such as the algorithms running on the
> Earth Simulator) use Fortran?

I don't know, but I suspect that it's a combination of the reasons that
I cited, and the fact that they incorporate significant amounts of older
Fortran code that predates the existence of C++ (and possibly even of C).

> As an undergrad, we were told that Fortran was more efficient for
> math-intensive algorithms. Is this true? Why is this the case and what
> sources cite this to be so?

It is more efficient to write, in many cases, because of the array syntax.

For calculations, this is a definite function of the compilers. In some
cases, Fortran syntax allows compilers to make more optimizations that C
or C++ syntax, but I am uncertain how much this matters in practice.

Another reason this could be true is that Fortran 77 only had static
array allocation, whereas C and C++ have the ability to do dynamic
allocation. If one misuses the latter ability in a way that causes one
to be continually allocating and deallocating arrays, that can cause a
performance problem.

> Do you suggest that I at least pick up some basic C/C++? If so, where
> should I start?

I suggest that you should pick up some basic C++; see above for why.

I will (somewhat flippantly) say that you should start by learning why
"C/C++" is meaningless in this context, and what the differences are.
Specifically, I think that what will be most useful for you to learn are
the things that are in C++ but not in C.

How I learned was to read a bit about object-oriented design, and then
pick a small project that I wanted to do that would work well with that.
And then I tried writing a program to implement it -- I wrote out a
rough design, and then for each piece I read through Bjarne Stroustrop's
_The C++ Programming Language_ until I figured out how to write it. For
some basic things involving pointers, that didn't really help much, and
so I asked my friends who know C++ about how to do that. (One of them
also loaned me a copy of Ellis and Stroustrop's _The Annotated C++
Reference Manual_, which was helpful for that sort of thing).

I do not know if I would recommend this method; it worked for me, but
that's in part because I knew a little bit of C once, and also I tend to
be rather different from a lot of people with regards to such things.
Also, it does involve a lot of reading and re-reading of large books.

I will, incidentally, recommend my method for picking from the vast
collection of C++ reference manuals at the local bookstore, once you
have a very little bit of knowledge: Think of a typical thing about C++
programming that want to look up in your new reference manual. Pick up
each book in turn, and try to find the answer to your question in the book.

Hope this helps!
- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Brooks Moses

2005-12-09, 7:18 pm

Rich Townsend wrote:
> You may instead be referring to the fact that aliasing is prohibited in many
> cases by Fortran, whereas it is very much a part of traditional C. Aliasing is a
> major cause of optimization bottlenecks. Note that C99 adds the 'restrict'
> keyword to mitigate aliasing issues, but I've yet to see code that uses it.

I know of one example -- there was some mention of it being used in a
bit of the gfortran compiler's source code, on the gfortran mailing list
a couple of days ago.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

James Van Buskirk

2005-12-09, 10:10 pm

"AN O'Nymous" <a_n_onymous80@yahoo.co.uk> wrote in message
news:1134138453.391502.214850@g44g2000cwa.googlegroups.com...

> So...why do you still use Fortran?

I find it's more natural to 'think out loud' in Fortran.
Here's a thought pattern for today: I was trying to reach
a matrix like the last but one matrix and it took me about
5 different attempts to make it work, but I did get it to
work out. It seems to me that this would be much more
difficult to do in other languages, not to mention how
much harder it would be in OSes like OSX or Linux, which
don't have the advanced facilities such as
mode con: cols=200
available to those of us at the MS-DOS Command Prompt.

! File: test5d.f90
! Public domain 2005 James Van Buskirk
! Like test5b, but reversed high time transforms
module mykinds
implicit none
integer, parameter :: dp = selected_real_kind(15,300)
integer, parameter :: qp_preferred = selected_real_kind(30,1000)
integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ &
(1-sign(1,qp_preferred))/2*dp
end module mykinds

module tensors
use mykinds
implicit none
interface operator(.tensor.)
module procedure tensor_product
end interface operator(.tensor.)
interface operator(.plus.)
module procedure direct_sum
end interface operator(.plus.)
real(qp), parameter :: RF2(2,2) = reshape((/1,1,1,-1/),(/2,2/))
contains
function tensor_product(A1,A2)
real(qp), intent(in) :: A1(:,:)
real(qp), intent(in) :: A2(:,:)
real(qp)
tensor_product(size(A1,1)*size(A2,1),siz
e(A1,2)*size(A2,2))
integer i1, i2, j1, j2

do i1 = 1, size(A1,1)
do i2 = 1, size(A2,1)
do j1 = 1, size(A1,2)
do j2 = 1, size(A2,2)

tensor_product((i1-1)*size(A2,1)+i2,(j1-1)*size(A2,2)+j2) = &
A1(i1,j1)*A2(i2,j2)
end do
end do
end do
end do
end function tensor_product

function direct_sum(A1,A2)
real(qp), intent(in) :: A1(:,:)
real(qp), intent(in) :: A2(:,:)
real(qp) direct_sum(size(A1,1)+size(A2,1),size(A1
,2)+size(A2,2))

direct_sum = 0
direct_sum(1:size(A1,1),1:size(A1,2)) = A1
direct_sum(size(A1,1)+1:,size(A1,2)+1:) = A2
end function direct_sum

function identity(n)
integer, intent(in) :: n
real(qp) identity(n,n)
integer i

identity = 0
do i = 1, n
identity(i,i) = 1
end do
end function identity

function checker(n)
integer, intent(in) :: n
real(qp) checker(n,n)
integer i

checker = 0
do i = 1, n
checker(i,i) = (-1)**(i-1)
end do
end function checker

function reverse(n)
integer, intent(in) :: n
real(qp) reverse(n,n)
integer i

reverse = 0
do i = 1, n
reverse(n+1-i,i) = 1
end do
end function reverse

function rf(n,k)
integer, intent(in) :: n
integer, intent(in), optional :: k
real(qp) rf(0:n-1,0:n-1)
real(qp) pi
integer i, j
real(qp) theta

pi = 4*atan(1.0_qp)
theta = 2*pi/n
if(present(k)) then
theta = theta*k
end if
! forall(i=0:n/2) rf(2*i,:) = (/(cos(theta*i*j),j=0,n-1)/)
! forall(i=n/2+1:n-1) rf(2*(i-n/2)-1,:) =
(/(sin(theta*(i-n/2)*j),j=0,n-1)/)
forall(i=0:n/2) rf(i,:) = (/(cos(theta*i*j),j=0,n-1)/)
! forall(i=n/2+1:n-1) rf(i,:) = (/(sin(theta*(i-n/2)*j),j=0,n-1)/)
forall(i=n/2+1:n-1) rf(i,:) = (/(sin(theta*(n-i)*j),j=0,n-1)/)
! forall(i=n/2+1:n-1) rf(i,:) = (/(sin(theta*i*j),j=0,n-1)/)
end function rf

function rfi(n,k)
integer, intent(in) :: n
integer, intent(in), optional :: k
real(qp) rfi(0:n-1,0:n-1)
real(qp) pi
integer i, j
real(qp) theta

pi = 4*atan(1.0_qp)
theta = 2*pi/n
if(present(k)) then
theta = theta*k
end if
! forall(i=0:n/2) rfi(:,2*i) = (/(cos(theta*i*j),j=0,n-1)/)
! forall(i=n/2+1:n-1) rfi(:,2*(i-n/2)-1) =
(/(sin(theta*(i-n/2)*j),j=0,n-1)/)
forall(i=0:n/2) rfi(:,i) = (/(cos(theta*i*j),j=0,n-1)/)
! forall(i=n/2+1:n-1) rfi(:,i) = (/(sin(theta*(i-n/2)*j),j=0,n-1)/)
forall(i=n/2+1:n-1) rfi(:,i) = (/(sin(theta*(n-i)*j),j=0,n-1)/)
! forall(i=n/2+1:n-1) rfi(:,i) = (/(sin(theta*i*j),j=0,n-1)/)
forall(i=0:n-1) rfi(:,i) = rfi(:,i)/dot_product(rfi(:,i),rfi(:,i))
end function rfi

subroutine print_mat(A)
real(qp), intent(in) :: A(:,:)
character(80) fmt

write(fmt,'(a,i0,a)') '(',size(A,2),'(f6.3:1x))'
write(*,fmt) transpose(A)
end subroutine print_mat

function stride(n,L)
integer, intent(in) :: n
integer, intent(in) :: L
real(qp) stride(0:n-1,0:n-1)
integer i, j

j = 0
stride = 0
do i = 0, n-1
stride(i,j) = 1
j = j+L
if(j >= n) j = j-n+1
end do
end function stride

function shuf1(x,p)
real(qp), intent(in) :: x(0:,0:)
integer, intent(in) :: p
real(qp) shuf1(0:size(x,1)-1,0:size(x,2)-1)
integer n, j
integer i, ishuf

n = size(x,1)
ishuf = 0
do i = 0, n-1, p
shuf1(ishuf,:) = x(i,:)
ishuf = ishuf+1
end do
do j = 1, (p-1)/2
do i = 0, n-1, p
shuf1(ishuf,:) = x(i+j,:)
ishuf = ishuf+1
shuf1(ishuf,:) = x(i+p-j,:)
ishuf = ishuf+1
end do
end do
end function shuf1
end module tensors

program test5
use mykinds
use tensors
implicit none
integer, parameter :: n = 5
real(qp) rf5(0:n-1,0:n-1)
real(qp) rfi5(0:n-1,0:n-1)
real(qp) rf25(0:n**2-1,0:n**2-1)
real(qp) i5(0:n-1,0:n-1)

rf5 = rf(n)
i5 = identity(n)
rf25 = rf(n**2)
call print_mat(rf25)
rfi5 = rfi(5,1)
write(*,'()')
rf25 = matmul(rf25,matmul(matmul(stride(n**2,n)
, &
(identity(3).tensor.rfi(5,1)).plus. &
(identity(2).tensor. matmul(reverse(5),rfi(5,1)))),stride(n**
2,n)))
call print_mat(rf25)
write(*,'()')
rf25 = shuf1(rf25,5)
call print_mat(rf25)
write(*,'()')
rf25(5:9,:) = matmul(transpose(rfi(5)),rf25((/5,7,9,8,6/),:))
rf25(10:14,:) = matmul(checker(5),rf25(10:14,:))
rf25(10:14,:) = rf25((/10,12,14,13,11/),:)
rf25(10:14,:) = matmul(transpose(rfi(5)),rf25(10:14,:))
rf25(15:19,:) = matmul(transpose(rfi(5)),rf25((/15,17,19,18,16/),:))
rf25(20:24,:) = matmul(checker(5),rf25(20:24,:))
rf25(20:24,:) = rf25((/20,22,24,23,21/),:)
rf25(20:24,:) = matmul(transpose(rfi(5)),rf25(20:24,:))
call print_mat(rf25)
!write(*,'(1x,f6.3,2(1x,f0.3))') rf25(6,6),
acos(rf25(6,6))/(8*atan(1.0_qp))*25, asin(rf25(6,6))/(8*atan(1.0_qp))*25
!write(*,'(1x,f6.3,2(1x,f0.3))') rf25(6,9),
acos(rf25(6,9))/(8*atan(1.0_qp))*25, asin(rf25(6,9))/(8*atan(1.0_qp))*25
!write(*,'(1x,f6.3,2(1x,f0.3))') rf25(9,6),
acos(rf25(9,6))/(8*atan(1.0_qp))*25, asin(rf25(9,6))/(8*atan(1.0_qp))*25
!write(*,'(1x,f6.3,2(1x,f0.3))') rf25(9,9),
acos(rf25(9,9))/(8*atan(1.0_qp))*25, asin(rf25(9,9))/(8*atan(1.0_qp))*25
!write(*,'(1x,f6.3,2(1x,f0.3))') rf25(11,6),
acos(rf25(11,6))/(8*atan(1.0_qp))*25, asin(rf25(11,6))/(8*atan(1.0_qp))*25
!write(*,'(1x,f6.3,2(1x,f0.3))') rf25(11,9),
acos(rf25(11,9))/(8*atan(1.0_qp))*25, asin(rf25(11,9))/(8*atan(1.0_qp))*25
!write(*,'(1x,f6.3,2(1x,f0.3))') rf25(14,6),
acos(rf25(14,6))/(8*atan(1.0_qp))*25, asin(rf25(14,6))/(8*atan(1.0_qp))*25
!write(*,'(1x,f6.3,2(1x,f0.3))') rf25(14,9),
acos(rf25(14,9))/(8*atan(1.0_qp))*25, asin(rf25(14,9))/(8*atan(1.0_qp))*25
write(*,'()')
call
print_mat((identity((n+1)/2).tensor.rf(n)).plus.(identity((n-1)/2).tensor.ma
tmul(rf(n),reverse(n))))
end program test5

Whoops -- some of the line wraps aren't looking good... well
I expect the reader can resolve them if necessary.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

Rich Townsend

2005-12-09, 10:10 pm

Brooks Moses wrote:
> Rich Townsend wrote:
>
>
>
> I know of one example -- there was some mention of it being used in a
> bit of the gfortran compiler's source code, on the gfortran mailing list
> a couple of days ago.
>
> - Brooks
>
>

Well, that's pretty aposite! Maybe it's only Fortran folk that still know what
aliasing is...

cheers,

Rich

ttw@texasairnet.com

2005-12-09, 10:10 pm

Ease of programming.
Speed of execution.
Simplicity of resultant code.
Portable as syphilis.

Greg Lindahl

2005-12-09, 10:10 pm

In article <dndfql$jbv$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:

> Maybe it's only Fortran folk that still know what
> aliasing is...

All compiler people struggle with aliasing on a regular basis.

-- greg

glen herrmannsfeldt

2005-12-09, 10:10 pm

David wrote:
> "AN O'Nymous" <a_n_onymous80@yahoo.co.uk> wrote in message
> news:1134138453.391502.214850@g44g2000cwa.googlegroups.com...

[color=darkred]
[color=darkred]
[color=darkred]
> Languages come and go. C has been around for a long time but it is best for
> short routines that interact with hardware. For developing numerical
> applications the choice may come down to Fortran or chasing the latest fad
> language. It has been my experience -- having spent much time chasing the
> latest fad -- that the small advantages gained using the latest languages
> are usually not worth the trouble it takes to learn them.

Well, a big advantage of Fortran is the many existing numerical packages
and routines available. It is possible to call them from C and some
other languages, though.

> If the purpose of the code is to interact with a PC running a Microsoft
> operating system than using a Microsoft supported language may make that
> easier. This is especially true if the code is not expected to have value
> for a long time. If the goal is to find a solution to a numerically
> intensive engineering problem (that does not interact with hardware),
> especially if the code may be used for many years to come, Fortran is a good
> choice.

[color=darkred]
> This may have something to do with the numerics being more important than
> the user interface or other IO which is machine dependent.

and maybe, again, the existing libraries. I don't know specifically,
but it may have originated many years ago, or adapted from older code.

[color=darkred]
> Fortran is designed to be efficient. It is possible to write C as efficient
> as Fortran but only if you really know C well. Fortran is efficient "by
> default".

Traditional (before ANSI) C did all floating point in double precision,
though with the ability to load and store into single precision
variables. While most numerical work is done in double precision, some
claimed that this was a C deficiency. Otherwise, C tends to be closer
to the machine, with mostly relatively low level operations. (Not so
much different than Fortran 66 in this regard.) Using some of the
newer features of Fortran can result in less efficient, though possibly
more readable, code.

Note that C and C++, though similar sounding, are very different
languages.
[color=darkred]
> Why not Java, Visual Basic or what ever comes next? C/C++ has many features
> that make it needlessly complex and error proned unles a programmer really
> knows what they are doing. It is not a language for the casual programmer.
> Both Java and VB are easier to do simple things with.

For an object-oriented language, I like Java more than C++, though
partly because it is more C like. C++ has many un-C like features that
I never liked at all. Each language is better suited for some problems
than others. It depends a lot on what you want to do.

-- glen

glen herrmannsfeldt

2005-12-09, 10:10 pm

Rich Townsend wrote:

(snip)

[color=darkred]
> I think you are

here. Sure, for a multidimensional array,
> Fortran and C access memory with a different index scheme (column major
> vs row major -- or the other way around). However, while this is
> important to consider when writing code that doesn't hammer the cache,
> it doesn't lead to a speed advantage of Fortran over C *per se*.

Except for people who get it wrong, I would have a hard time
believing this was a big problem.

> You may instead be referring to the fact that aliasing is prohibited in
> many cases by Fortran, whereas it is very much a part of traditional C.
> Aliasing is a major cause of optimization bottlenecks. Note that C99
> adds the 'restrict' keyword to mitigate aliasing issues, but I've yet to
> see code that uses it.

Another difference is to do dynamically allocated multidimensional
arrays it usual in C to use arrays of pointers to arrays. It is hard to
say in general which is faster. I first heard of this being done on the
DEC PDP-11 Fortran compilers, which did it internally as it was faster
than multiplying.

Steven G. Kargl

2005-12-09, 10:10 pm

In article <dndfql$jbv$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> writes:
> Brooks Moses wrote:
>
> Well, that's pretty aposite! Maybe it's only Fortran folk that still know what
> aliasing is...
>

Brooks is correct. The restrict keyword appears at least in the
code for matmul and dot_product. I haven't checked, but it probably
appears in all the array intrinsic procedure. IIRC, restrict
provided some significant speed ups because gcc of course can do
additional optimizations.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Rich Townsend

2005-12-10, 4:14 am

Greg Lindahl wrote:
> In article <dndfql$jbv$1@scrotar.nss.udel.edu>,
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
>
>
>
>
> All compiler people struggle with aliasing on a regular basis.
>

You wouldn't know that to talk to a computer scientist.

cheers,

Rich

James Giles

2005-12-10, 4:14 am

Rich Townsend wrote:
> Greg Lindahl wrote:
....[color=darkred]
....[color=darkred]
....[color=darkred]
> You wouldn't know that to talk to a computer scientist.

But, isn't that one of the things that makes "computer scientist"
an oxymoron?

--
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

David

2005-12-10, 4:14 am

"Brooks Moses" <bmoses-nospam@cits1.stanford.edu> wrote in message
news:439A1C05.8010601@cits1.stanford.edu...
> AN O'Nymous wrote:
>
> I think that's an unwise idea. Spending the time to learn another
> language (particularly one that's conceptually different from what you are
> used to, like C++) will introduce you to other ideas about how programs
> can be structured. This will give you a broader toolset that you can then
> use when designing programs to be written in Fortran.
>

Some types of applications are much easier to write using an "object
oriented" approach. I learned most of what I know about OOP from books on
C++.

AN O'Nymous

2005-12-10, 8:13 am

Thanks everyone, and Brooks for your informative reply. You're
absolutely right, I realise now that "programming" itself is the skill,
and not "programming in Fortran".

I've found one copy of "C++ for dummies" at my college's library, and
have placed a hold for it :-) (I found this series a good introduction
to HTML in the past)

Thanks again.

Gary L. Scott

2005-12-10, 7:14 pm

James Giles wrote:

> Rich Townsend wrote:
>
>
> ...
>
>
> ...
>
>
> ...
>
>
>
> But, isn't that one of the things that makes "computer scientist"
> an oxymoron?
>

Ouch, straight through the heart...may be one of the reasons we use a
lot of EEs and EETs in software positions...

--

Gary Scott
mailto:garyscott@ev1.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

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Ian Chivers

2005-12-10, 7:14 pm

Another useful resource I've found is

http://www.accu.org/bookreviews/public/index.htm

for c, c++, java and c#

their base address is

http://www.accu.org/

"Tim Prince" <tprince@nospamcomputer.org> wrote in message
news:6rhmf.29032$7h7.2459@newssvr21.news.prodigy.com...
> Ronald Benedik wrote:
>
> The consensus on comp.lang.C (an excellent resource) heartily
> disrecommends his books.

Greg Lindahl

2005-12-10, 7:14 pm

In article <dndpco$lvh$1@scrotar.nss.udel.edu>,
Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:

>
>You wouldn't know that to talk to a computer scientist.

Well, yeah, but those are the ones who can't get jobs working on
compilers.

-- greg

Rich Townsend

2005-12-10, 7:14 pm

Greg Lindahl wrote:
> In article <dndpco$lvh$1@scrotar.nss.udel.edu>,
> Rich Townsend <rhdt@barVOIDtol.udel.edu> wrote:
>
>
>
>
> Well, yeah, but those are the ones who can't get jobs working on
> compilers.

....which appears to be the vast majority. The ones who end up coding
point-and-drool interfaces in C#.

Jim Klein

2005-12-10, 10:10 pm

Why not !
James E. Klein
jameseklein@earthlink.net

Engineering Calculations
http://home.earthlink.net/~76403795
76403795@earthlink.net
Engineering Calculations is the home of
the KDP-2 Optical Design Program
for Windows and (soon) MAC OSX
Free version 2.0 downloadable!

mcalhoun@ksu.edu

2005-12-11, 7:17 pm

NNTP-Posting-Host: unix1.cc.ksu.edu
X-Trace: cnn.cns.ksu.edu 1134322619 6189 129.130.12.3 (11 Dec 2005 17:36:59 GMT)
X-Complaints-To: abuse@ksu.edu
NNTP-Posting-Date: Sun, 11 Dec 2005 17:36:59 +0000 (UTC)
X-Newsreader: NN version 6.5.0 #2 (NOV)
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:140616

>....[snip]....
>Likewise, the right Fortran book depends on whether Fortran is the first
>programming language of the reader, or if the reader has natural talent...

I found the following books to be quite helpful for learning C:

"On to C" by Patrick Henry Winston (IIRC, he also wrote "On to C++"), in
44 short chapters (the entire book is only 289 pages long), teaches
one "the essentials of C programming". My flyleaf note for my 1994
copy says:
"Except for the typos, best text I've read in years!"
(I could supply a list of typos if requested)

"Beginning with C: An Introduction to Professional Programming" by
Ron House is similar to Winston's book (but twice as thick!)

"Efficient C Programming: A Practical Approach" by Mark Allen Weiss
gives many nitty-gritty details of how C actually works or how
it can be made to do something that isn't obvious.

I agree with Brooks Moses <bmoses-nospam@cits1.stanford.edu> comment:
>.... Spending the time to learn another language (particularly one
>that's conceptually different from what you are used to, like C++)
>will introduce you to other ideas about how programs can be structured.
>This will give you a broader toolset that you can then use when
>designing programs to be written in Fortran.

FWIW, I taught FORTRAN for many years, and 99% of my personal coding is
still Fortran. However, I've also taught BASIC, COBOL, Modula-2, Pascal,
(and maybe others, but my brain is getting old enough to forget) and
several assembly languages, and I have designed and written compilers or
preprocessors or interpretors for several mini-languages.

Many people turn their noses up on COBOL, for example, but I found it to
be a VERY INTERESTING language and occassionally incorporate what COBOL
calls "control-break" programming into FORTRAN code.
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
PhD EE (retired). "Barbershop" tenor. CDL(PTXS). W0PBV. (785) 539-4448
NRA Life Member and Certified Instructor (Home Firearm Safety, Rifle, Pistol)

Brooks Moses

2005-12-11, 7:17 pm

mcalhoun@ksu.edu wrote:
> FWIW, I taught FORTRAN for many years, and 99% of my personal coding is
> still Fortran. However, I've also taught BASIC, COBOL, Modula-2, Pascal,
> (and maybe others, but my brain is getting old enough to forget) and
> several assembly languages, and I have designed and written compilers or
> preprocessors or interpretors for several mini-languages.
>
> Many people turn their noses up on COBOL, for example, but I found it to
> be a VERY INTERESTING language and occassionally incorporate what COBOL
> calls "control-break" programming into FORTRAN code.

Any chance that this "control-break" programming concept is something
that you could explain in a few paragraphs? If so, I'd be interested in
hearing it.

- Brooks

--
The "bmoses-nospam" address is valid; no unmunging needed.

Stewart Gordon

2005-12-15, 7:57 am

David wrote:
> "Stewart Gordon" <smjg_1998@yahoo.com> wrote in message
> news:dncaaa$1f9$1@sun-cc204.lut.ac.uk...
<snip>[color=darkred]
>
> I think it is the multidimensional arrays that are the issue.
<snip>

So you think that Fortran's multidimensional arrays, which are
variable-size in all dimensions, are faster than C arrays in which all
dimensions (except the outermost, depending on circumstances) have to be
compile-time constants?

Stewart.

--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:- C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS-
PE- Y? PGP- t- 5? X? R b DI? D G e++>++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox. Please keep replies on
the 'group where everyone may benefit.

Jan Vorbrüggen

2005-12-15, 7:57 am

> So you think that Fortran's multidimensional arrays, which are
> variable-size in all dimensions, are faster than C arrays in which all
> dimensions (except the outermost, depending on circumstances) have to be
> compile-time constants?

No. Fortran gives you the option of having all dimensions variable at
run time, you don't _have_ to go that way. And in this day and age, with
processors that have plenty of register 8-|, pre-computing the stride in
the inner loop of a loop nest and incrementing by that - instead of by a
compile-time constant - is going to have negligible performance impact.

Even in 1985 or so, on a - relatively - register-starved VAX (only 16
instead of the usual 64 registers), the Fortran compiler was excellent
at this exercise. Often, it produced code that used the VAX's auto-
incrementing addressing modes to good effect.

Jan

mcalhoun@ksu.edu

2005-12-16, 7:04 pm

Yes, I will, but IT MAY BE FEBRUARY before I can do it, what with the
Xmas season, the fact that I'm getting ready to teach a course ("Don't
Shoot Yourself in the Foot"!) in Iowa during the entire month of January,
and several other excuses.

But, "the Good Lord willing and the cr

don't rise", I will NOT forget!

[color=darkred]
>Any chance that this "control-break" programming concept is something
>that you could explain in a few paragraphs? If so, I'd be interested in
>hearing it.
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
PhD EE (retired). "Barbershop" tenor. CDL(PTXS). W0PBV. (785) 539-4448
NRA Life Member and Certified Instructor (Home Firearm Safety, Rifle, Pistol)

glen herrmannsfeldt

2005-12-18, 3:56 am

Jan Vorbrüggen wrote:

(snip)

> Even in 1985 or so, on a - relatively - register-starved VAX (only 16
> instead of the usual 64 registers), the Fortran compiler was excellent
> at this exercise. Often, it produced code that used the VAX's auto-
> incrementing addressing modes to good effect.

Presumably not using the BOUNDS instruction specifically designed to
do array subscript calculations but well known to be slower than doing
it without the BOUNDS instruction.

(Or is it BOUND, I forget now.)

-- glen

Jan Vorbrüggen

2006-01-10, 4:10 am

> Presumably not using the BOUNDS instruction specifically designed to
> do array subscript calculations but well known to be slower than doing
> it without the BOUNDS instruction.

No, it never did that 8-).

Jan

mcalhoun@ksu.edu

2006-01-31, 7:02 pm

>>> Many people turn their noses up on COBOL, for example, but I found it to[color=darkred]
[color=darkred]

I taught INTRODUCTION TO BUSINESS PROGRAMMING (commonly called "COBOL"!)
nine semesters from 1988 through 1996, mostly to students enrolled in an
"Information Technology" curriculum. Having heard horror stories about
how bad COBOL was as a programming language, I approached the first
semester with fear and trepidation, but, after learning that COBOL,
although different and rather simple, is (was?) a rather "neat"
language, I enjoyed every minute of it!

Quoting from Chapter 9 of A SIMPLIFIED GUIDE TO STRUCTURED COBOL
PROGRAMMING (Second Edition), by Daniel D. McCracken (old-time FORTRAN
programmers probably remember his FORTRAN book!) and Donald G. Golden:

The primary topic for this chapter is the processing of a file that
is in sequence on some field in each record, building a report that
is organized according to the changes in that field. A change from
one account group to the next is called a "control break", hence the
title of the chapter.

The vehicle for this study will be an application of broad general
interest. Starting with a file of sales data that is in ascending
sequence, we are to produce a summary of the data by region, seller,
and account. The techniques involved in processing such a file are
of fundamental importance ....

Suppose we have an input file of information about the previous
month's sales of some company. The company has a number of sales
regions; within each region there are a number of salespeople; each
salesperson handles a number of accounts. We are required to
produce a sales summary that shows the total sales for the entire
company for the month, the total sales for each region, the total
sales for each salesperson, and the total sales for each account.

....

The pseudocode for this program is shown [below; I've abbreviated
it a bit and added some comments enclosed in square brackets]:

PRODUCE SALES REPORT:
open files
set final-total to zero
set more-data-flag to 'Y'
get account record; at end set more-data-flag to 'N'
PERFORM-UNTIL no-more-data ["automagic" comparison: more-data-flag == 'N']
process region group
ENDPERFORM
print final-total
close files
stop run [STOP RUN is a COBOL command!]

PROCESS REGION GROUP:
set region-total to zero
set previous-region-number to region-number of current record
PERFORM-UNTIL
region-number is not equal to previous-region-number
OR no-more-data
process seller group
ENDPERFORM
print region line
update final-total

PROCESS SELLER GROUP:
set seller-total to zero
set previous-seller-number to seller-number of current record
PERFORM-UNTIL
seller-number is not equal to previous-seller-number
OR region-number is not equal to previous-region-number
OR no-more-data
process account group
ENDPERFORM
print seller line
update region-total

PROCESS ACCOUNT GROUP:
set account-total to zero
set previous-account-number to account-number of current record
PERFORM-UNTIL
account-number is not equal to previous-account-number
OR seller-number is not equal to previous-seller-number
OR region-number is not equal to previous-region-number
OR no-more-data
update account total
get account record; at end set more-data-flag to 'N'
ENDPERFORM
print account line
update seller-total

Some things to notice:
* PRODUCE SALES REPORT, PROCESS REGION GROUP, PROCESS SELLER GROUP, and
PROCESS ACCOUNT GROUP are "paragraphs", and paragraphs are vaguely
similar to SUBROUTINEs in that they allow "grouping" of code.
* Program flow CAN pass from one paragraph to another, but if a paragraph
is "called" from somewhere else (the COBOL word is PERFORM), then the
end of a paragraph causes an automagic "return".
* Hyphenated words in the above pseudocode evenually become variable
names/identifiers. (There are so MANY reserved words in COBOL -- about
400, IIRC -- that creating identifiers DIFFERENT from reserved words
can be difficult!)
* All variables are global (true SUBROUTINEs and parameter passing ARE
possible, but they aren't even introduced until chapter 18 of 20!)
* All the PROCESS ... GROUP paragraphs look pretty-much alike.
(In fact, after typing PROCESS REGION GROUP, I just duplicated
it twice and changed the appropriate words!)
* EXCEPT that the PERFORM-UNTIL clause of each "lower level" paragraph
gets longer and longer, because the input data may cause a
"control-break" for more and more reasons:
account-number is not equal to previous-account-number
OR seller-number is not equal to previous-seller-number
OR region-number is not equal to previous-region-number
OR no-more-data

And that is "control break" programming. Once, just for the fun of it,
I used FORTRAN ASSIGN statements to give names to statement numbers and
then translated a COBOL program to FORTRAN (I did have to drop the hyphens
from variable names!-) and ended up with something a COBOL programmer
(or a managerial-type person) would have been able read.

Feel free to ask further questions.

--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
PhD EE (retired). "Barbershop" tenor. CDL(PTXS). W0PBV. (785) 539-4448
NRA Life Member and Certified Instructor (Home Firearm Safety, Rifle, Pistol)

Richard E Maine

2006-01-31, 7:02 pm

<mcalhoun@ksu.edu> wrote:

> * Program flow CAN pass from one paragraph to another, but if a paragraph
> is "called" from somewhere else (the COBOL word is PERFORM), then the
> end of a paragraph causes an automagic "return".

Oh yeah. I remember that feature. While I am tempted to comment further,
prudence dicates otherwise. This doesn't really seem the right group for
what I'd say about it anyway. Perhaps something like alt.obscenties.
:-)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Sponsored Links