Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
Learning Fortran

Subject: Learning Fortran

From: Baalzamon

Date: 20 May, 2010 11:37:04

Message: 1 of 58

I am attempting to convert some old fortran codes and becoming somewhat annoyed by the apparent jumping of code. WOuld I be correct in assuming that the code is read top to bottom and in line number order? If so where does the do label numbers figure into this scheme? Any advice from fortan programmers would be appreciated. To be explicit I think the coxde was written in F77...

Subject: Learning Fortran

From: Rune Allnor

Date: 20 May, 2010 12:18:04

Message: 2 of 58

On 20 Mai, 13:37, "Baalzamon " <baalzamon_mori...@yahoo.com> wrote:
> I am attempting to convert some old fortran codes and becoming somewhat annoyed by the apparent jumping of code.

The infamous spaghetti style coding

http://en.wikipedia.org/wiki/Spaghetti_code

is the main reason why you ought not learn fortran at all.
It was obsolete 40 years ago. The only reason it remains
in use is the vast amount of legacy code present.


> WOuld I be correct in assuming that the code is read top to bottom and in line number order?

No. It *starts* that way, but from the first jump / break /
continue /
goto statement you are on your own with respect to untangling program
flow. Hence the spaghetti metafor.

> If so where does the do label numbers figure into this scheme?

They are the spots at which a jump / break / continue / goto might
refer. One serious problem with fortran is that there is no
convenient
way to find out where the jump that landed on the label was made.

> Any advice from fortan programmers would be appreciated. To be explicit I think the coxde was written in F77...

Don't write fortran. It might be more cost effective to find
out what the program is supposed to do, and then develop and
code the algorithm from scratch in matlab, C, C++ or Java.

No kidding.

Rune

Subject: Learning Fortran

From: Baalzamon

Date: 20 May, 2010 12:26:04

Message: 3 of 58

Ah right much thanks. I don't intend to actually learn fortran - or rather just enough to understand the darn code. Well i'll ontinue my attemts at following it but like you suggested i might just see if i can obtain the actual maths behind this code and attempt to implement it straight into matlab. Fun Fun Fun?
Anyway thanks for the reply.

Subject: Learning Fortran

From: Rune Allnor

Date: 20 May, 2010 13:36:52

Message: 4 of 58

On 20 Mai, 14:26, "Baalzamon " <baalzamon_mori...@yahoo.com> wrote:
> Ah right much thanks. I don't intend to actually learn fortran - or rather just enough to understand the darn code. Well i'll ontinue my attemts at following it but like you suggested i might just see if i can obtain the actual maths behind this code and attempt to implement it straight into matlab. Fun Fun Fun?

Fact of Life. And a reason for paying accute attention to
the algorithm development and documentation as opposed to
the source code. Whenever I implement something, I write a
companion document where all the minute deliberations are
recorded. I might not use the first matlab version for
eternity, but as long as I have access to that document
I can implement the algorithm in whatever language in a
matter of hours.

Rune

Subject: Learning Fortran

From: dpb

Date: 20 May, 2010 13:39:06

Message: 5 of 58

Baalzamon wrote:
> Ah right much thanks. I don't intend to actually learn fortran - or
> rather just enough to understand the darn code. Well i'll ontinue my
> attemts at following it but like you suggested i might just see if i can
> obtain the actual maths behind this code and attempt to implement it
> straight into matlab. Fun Fun Fun?
> Anyway thanks for the reply.

Fortran is _NOT_ obsolete; the last Standard was for F2003 and F2008 is
in process. F77 was supplanted by F90/95 which incorporated much of
dynamic memory and other features. Control for structured programming
have been in common extensions since well before F77 and F77 formalized
IF blocks while F90 standardized CASE and DO WHILE, etc.

The answer to the specific questions you posed are...

a) Yes, code is sequential until a branch path is taken

b) Label numbers are only significant as the target for a branch (GOTO
computed IF, DO construct end or ERR= or END= location, etc.). The
magnitude of the label is not significant altho most coders had a
general convention the value itself is immaterial to the structure of
the code; it's just a label.

One key to Fortran that sometimes puzzles those who come from a C
background--the scope of Fortran compilation is the program unit, which
is _NOT_ the file but the individual PROGRAM, FUNCTION or SUBROUTINE mor
than one of which can be contained within a single file. Thus there are
not "file scope" variables, etc. For F77, global variables, if any,
typically will be in COMMON blocks (hopefully all of which will be
named, not blank COMMON).

There are tools that can help -- I've been very pleased w/ the
demonstration/trial usage of the "Understand for XXXX_Language"
analyzers from Scientific Toolworks <www.scitools.com> to help in
digging into legacy code. At the last time I actually had need altho
I've been retired for a few years now, it was still available fully
functional for a reasonable time as a free download that was sufficient
to accomplish a relatively small task such as yours sounds as if would
be. I know there are some other open source tools but I don't have a
handle on them; requests along that line would best be posted to
comp.lang.fortran instead of c.s-s.m. Also, if have future specific
questions regarding the code itself c.l.f is active and very helpful w/
several who are both ML and Fortran-literate.

--

Subject: Learning Fortran

From: James Tursa

Date: 20 May, 2010 13:43:04

Message: 6 of 58

"Baalzamon " <baalzamon_moridin@yahoo.com> wrote in message <ht36t0$dc8$1@fred.mathworks.com>...
> I am attempting to convert some old fortran codes and becoming somewhat annoyed by the apparent jumping of code. WOuld I be correct in assuming that the code is read top to bottom and in line number order? If so where does the do label numbers figure into this scheme? Any advice from fortan programmers would be appreciated. To be explicit I think the coxde was written in F77...

You could try to use an automated converter to get the bulk of the conversion done. e.g., here:

http://www.mathworks.com/matlabcentral/fileexchange/5260-f2matlab

Another alternative is to leave the Fortran code basically intact but put a front end mex interface on it so you can call it directly from MATLAB.

How large is the code?

James Tursa

Subject: Learning Fortran

From: Steven Lord

Date: 20 May, 2010 16:15:50

Message: 7 of 58


"dpb" <none@non.net> wrote in message
news:ht3e5a$r7h$1@news.eternal-september.org...
> Baalzamon wrote:

*snip*

> Also, if have future specific questions regarding the code itself c.l.f is
> active and very helpful w/ several who are both ML and Fortran-literate.

For clarification, since the OP (Original Poster) and others may not be
familiar with the abbreviation: c.l.f refers to the comp.lang.fortran
newsgroup, which should be available via Google Groups
(http://groups.google.com) or other sites that provide general access to
newsgroups.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: Learning Fortran

From: dpb

Date: 20 May, 2010 18:35:06

Message: 8 of 58

Steven Lord wrote:
> "dpb" <none@non.net> wrote in message
> news:ht3e5a$r7h$1@news.eternal-september.org...
>> Baalzamon wrote:
>
> *snip*
>
>> Also, if have future specific questions regarding the code itself c.l.f is
>> active and very helpful w/ several who are both ML and Fortran-literate.
>
> For clarification, since the OP (Original Poster) and others may not be
> familiar with the abbreviation: c.l.f refers to the comp.lang.fortran
> newsgroup, which should be available via Google Groups
> (http://groups.google.com) or other sites that provide general access to
> newsgroups.

Yes, I had spelled it out in the previous sentence before abbreviating... :)

As for access, the free newsservers from news.eternal-september.org that
I'm currently using or aioe.org mirror comp.lang.fortran as well as cssm
so a news reader can be pointed to the server rather than requiring the
use of the terrible google-groups web interface. Nothing other than a
registration w/ a valid e-mail address is required of either; access is
generally available within a few hours of signup after their access
update 'bot runs...

--

Subject: Learning Fortran

From: Steven Lord

Date: 20 May, 2010 21:36:46

Message: 9 of 58


"dpb" <none@non.net> wrote in message
news:ht3vgb$tl1$1@news.eternal-september.org...
> Steven Lord wrote:
>> "dpb" <none@non.net> wrote in message
>> news:ht3e5a$r7h$1@news.eternal-september.org...

*snip*

>> For clarification, since the OP (Original Poster) and others may not be
>> familiar with the abbreviation: c.l.f refers to the comp.lang.fortran
>> newsgroup, which should be available via Google Groups
>> (http://groups.google.com) or other sites that provide general access to
>> newsgroups.
>
> Yes, I had spelled it out in the previous sentence before abbreviating...
> :)

*blink*

*blink*

I KNOW I read through your posting to try to make sure you _hadn't_ used the
full term before I posted. At least twice.

*sigh*

Guess I need to either make an appointment with the eye doctor or to avoid
quickly checking CSSM just before heading to lunch.

Sorry.

--
Steve Lord
slord@mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: Learning Fortran

From: Greg Heath

Date: 21 May, 2010 01:46:06

Message: 10 of 58

On May 20, 8:18 am, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 20 Mai, 13:37, "Baalzamon " <baalzamon_mori...@yahoo.com> wrote:
>
> > I am attempting to convert some old fortran codes and becoming somewhat annoyed by the apparent jumping of code.
>
> The infamous spaghetti style coding
>
> http://en.wikipedia.org/wiki/Spaghetti_code
>
> is the main reason why you ought not learn fortran at all.
> It was obsolete 40 years ago. The only reason it remains
> in use is the vast amount of legacy code present.
>
> > WOuld I be correct in assuming that the code is read top to bottom and in line number order?
>
> No. It *starts* that way, but from the first jump / break /
> continue /
> goto statement you are on your own with respect to untangling program
> flow. Hence the spaghetti metafor.
>
> > If so where does the do label numbers figure into this scheme?
>
> They are the spots at which a jump / break / continue / goto might
> refer. One serious problem with fortran is that there is no
> convenient
> way to find out where the jump that landed on the label was made.
>
> > Any advice from fortan programmers would be appreciated. To be explicit I think the coxde was written in F77...
>
> Don't write fortran. It might be more cost effective to find
> out what the program is supposed to do, and then develop and
> code the algorithm from scratch in matlab, C, C++ or Java.
>
> No kidding.

I have had the pleasure of disentangling a FORTRAN
numerical optimization program that used a plethora of
subroutines and goto/contimue statements. When finished,
the FORTRAN code was not dissimilar to that used in
MATLAB. However, I had no incentive to convert it to
MATLAB because I didn't know how to compile MATLAB
to make it run as fast.

A lot depends on how comfortable you are with FORTRAN,
what you plan to do with the program in the futire, and how
much time you can spare.

Hope this helps.

Greg

Subject: Learning Fortran

From: TideMan

Date: 21 May, 2010 02:36:57

Message: 11 of 58

On May 21, 1:46 pm, Greg Heath <he...@alumni.brown.edu> wrote:
> On May 20, 8:18 am, Rune Allnor <all...@tele.ntnu.no> wrote:
>
>
>
> > On 20 Mai, 13:37, "Baalzamon " <baalzamon_mori...@yahoo.com> wrote:
>
> > > I am attempting to convert some old fortran codes and becoming somewhat annoyed by the apparent jumping of code.
>
> > The infamous spaghetti style coding
>
> >http://en.wikipedia.org/wiki/Spaghetti_code
>
> > is the main reason why you ought not learn fortran at all.
> > It was obsolete 40 years ago. The only reason it remains
> > in use is the vast amount of legacy code present.
>
> > > WOuld I be correct in assuming that the code is read top to bottom and in line number order?
>
> > No. It *starts* that way, but from the first jump / break /
> > continue /
> > goto statement you are on your own with respect to untangling program
> > flow. Hence the spaghetti metafor.
>
> > > If so where does the do label numbers figure into this scheme?
>
> > They are the spots at which a jump / break / continue / goto might
> > refer. One serious problem with fortran is that there is no
> > convenient
> > way to find out where the jump that landed on the label was made.
>
> > > Any advice from fortan programmers would be appreciated. To be explicit I think the coxde was written in F77...
>
> > Don't write fortran. It might be more cost effective to find
> > out what the program is supposed to do, and then develop and
> > code the algorithm from scratch in matlab, C, C++ or Java.
>
> > No kidding.
>
> I have had the pleasure of disentangling a FORTRAN
> numerical optimization program that used a plethora of
> subroutines and goto/contimue statements. When finished,
> the FORTRAN code was not dissimilar to that used in
> MATLAB. However, I had no incentive to convert it to
> MATLAB because I didn't know how to compile MATLAB
> to make it run as fast.
>
> A lot depends on how comfortable you are with FORTRAN,
> what you plan to do with the program in the futire, and how
> much time you can spare.
>
> Hope this helps.
>
> Greg

Yes, I agree, Greg.
Mostly, I develop algorithms in Matlab, then translate into Fortran 95
for speed and for distribution.
My clients compile and link my code on their machines (either Windows
or Linux) and away they go.
No expensive Matlab compiler required. No cross-platform
difficulties. And gfortran is free.

I wouldn't worry about old Rune's comments.
He's just trying to wind people up.
He's like a broken record.
He says the same thing everytime this comes up.

Subject: Learning Fortran

From: Rune Allnor

Date: 21 May, 2010 09:34:04

Message: 12 of 58

On 21 Mai, 03:46, Greg Heath <he...@alumni.brown.edu> wrote:
> On May 20, 8:18 am, Rune Allnor <all...@tele.ntnu.no> wrote:
>
>
>
>
>
> > On 20 Mai, 13:37, "Baalzamon " <baalzamon_mori...@yahoo.com> wrote:
>
> > > I am attempting to convert some old fortran codes and becoming somewhat annoyed by the apparent jumping of code.
>
> > The infamous spaghetti style coding
>
> >http://en.wikipedia.org/wiki/Spaghetti_code
>
> > is the main reason why you ought not learn fortran at all.
> > It was obsolete 40 years ago. The only reason it remains
> > in use is the vast amount of legacy code present.
>
> > > WOuld I be correct in assuming that the code is read top to bottom and in line number order?
>
> > No. It *starts* that way, but from the first jump / break /
> > continue /
> > goto statement you are on your own with respect to untangling program
> > flow. Hence the spaghetti metafor.
>
> > > If so where does the do label numbers figure into this scheme?
>
> > They are the spots at which a jump / break / continue / goto might
> > refer. One serious problem with fortran is that there is no
> > convenient
> > way to find out where the jump that landed on the label was made.
>
> > > Any advice from fortan programmers would be appreciated. To be explicit I think the coxde was written in F77...
>
> > Don't write fortran. It might be more cost effective to find
> > out what the program is supposed to do, and then develop and
> > code the algorithm from scratch in matlab, C, C++ or Java.
>
> > No kidding.
>
> I have had the pleasure of disentangling a FORTRAN
> numerical optimization program that used a plethora of
> subroutines and goto/contimue statements.

You're into the S&M scene, then?

> When finished,
> the FORTRAN code was not dissimilar to that used in
> MATLAB.

What, exactly, do you mean by 'disentangling' fortran?
Understand what's going on? Re-write the mess?

> However, I had no incentive to convert it to
> MATLAB because I didn't know how to compile MATLAB
> to make it run as fast.

Use C or C++ instead.

> A lot depends on how comfortable you are with FORTRAN,

There is no reason why anywone would want to let a
half-century-old seriously flawed programming language
guide your day. Fortran was among the first high-level
programming languages around, and a number of serious
mistakes were made that designers of later languages
have made more or less successful attempts to rectify.

'Structured programming' of the early '70s represented
a revolution by breaking code up in individually easily
understandable functions. Object oriented programming
of the late '70s took that a lightyear further.

> what you plan to do with the program in the futire,

I don't mind if *you* have no other ambitions than
messing around on your own.

Just don't rely on - expect, even - others to have as unassuming
ambitions as yourself.

> and how
> much time you can spare.

No. How much time you, the fortram programmer, wastes on
the subsequent maintaner's behalf. Again, I don't mind you
wasting your own time. I *do* mind you wasting somebody
else's. Particularly mine.

Rune

Subject: Learning Fortran

From: Rune Allnor

Date: 21 May, 2010 09:48:18

Message: 13 of 58

On 21 Mai, 04:36, TideMan <mul...@gmail.com> wrote:

> I wouldn't worry about old Rune's comments.

Well, am am actually young enough never to have to had to learn
fortran. The old people here are those who are so stuck in their
old habits, unable to learn the methods that actually work.

> He's just trying to wind people up.

No. I am trying to guide youngsters and novices away from the
pitfalls that have been known for decades already. Read the
opening sentence of the classic paper

   Go To Statement Considered Harmful
   Commmunications of the ACM VoL11 (2), 1968 pp. 147-148
   Edsger W. Dijkstra:

  "For a number of years I have been familiar with the observation
   that the quality of programmers is a decreasing function of the
   density of go to statements in the programs they produce."

I couldn't agree more.

> He's like a broken record.

If so, it is because the same old farts and amateurs are guiding the
youngsters and novices into the same well-known traps. As I said to
somebody else, I don't mind you wasting your *own* time, but I
do mind you wasting *other* people's time.

These things aren't difficult to get right. It's only a matter of
letting go of the time of *your* youth.

> He says the same thing everytime this comes up.

Of course. As long as fortran is around and being discussed, its
flaws must be addressed.

Rune

Subject: Learning Fortran

From: Steve Amphlett

Date: 21 May, 2010 10:13:05

Message: 14 of 58

Rune Allnor <allnor@tele.ntnu.no> wrote in message <1a16015e-0539-442e-bb29-958448ed6972@y21g2000vba.googlegroups.com>...
> On 21 Mai, 04:36, TideMan <mul...@gmail.com> wrote:
>
> > I wouldn't worry about old Rune's comments.
>
> Well, am am actually young enough never to have to had to learn
> fortran. The old people here are those who are so stuck in their
> old habits, unable to learn the methods that actually work.
>
> > He's just trying to wind people up.
>
> No. I am trying to guide youngsters and novices away from the
> pitfalls that have been known for decades already. Read the
> opening sentence of the classic paper
>
> Go To Statement Considered Harmful
> Commmunications of the ACM VoL11 (2), 1968 pp. 147-148
> Edsger W. Dijkstra:
>
> "For a number of years I have been familiar with the observation
> that the quality of programmers is a decreasing function of the
> density of go to statements in the programs they produce."
>
> I couldn't agree more.
>
> > He's like a broken record.
>
> If so, it is because the same old farts and amateurs are guiding the
> youngsters and novices into the same well-known traps. As I said to
> somebody else, I don't mind you wasting your *own* time, but I
> do mind you wasting *other* people's time.
>
> These things aren't difficult to get right. It's only a matter of
> letting go of the time of *your* youth.
>
> > He says the same thing everytime this comes up.
>
> Of course. As long as fortran is around and being discussed, its
> flaws must be addressed.
>
> Rune

I really enjoy reading the anti-FORTRAN flame wars here. Of the FORTRAN being written today, I wonder how much of it is simply adding features to legacy code and how much of it is new code, using all the bells and whistles added to it over the years to keep the name alive?

Subject: Learning Fortran

From: Rune Allnor

Date: 21 May, 2010 10:45:01

Message: 15 of 58

On 21 Mai, 12:13, "Steve Amphlett" <Firstname.Lastn...@Where-I-
Work.com> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message <1a16015e-0539-442e-bb29-958448ed6...@y21g2000vba.googlegroups.com>...
> > On 21 Mai, 04:36, TideMan <mul...@gmail.com> wrote:
>
> > > I wouldn't worry about old Rune's comments.
>
> > Well, am am actually young enough never to have to had to learn
> > fortran. The old people here are those who are so stuck in their
> > old habits, unable to learn the methods that actually work.
>
> > > He's just trying to wind people up.
>
> > No. I am trying to guide youngsters and novices away from the
> > pitfalls that have been known for decades already. Read the
> > opening sentence of the classic paper
>
> >    Go To Statement Considered Harmful
> >    Commmunications of the ACM VoL11 (2), 1968 pp. 147-148
> >    Edsger W. Dijkstra:
>
> >   "For a number of years I have been familiar with the observation
> >    that the quality of programmers is a decreasing function of the
> >    density of go to statements in the programs they produce."
>
> > I couldn't agree more.
>
> > > He's like a broken record.
>
> > If so, it is because the same old farts and amateurs are guiding the
> > youngsters and novices into the same well-known traps. As I said to
> > somebody else, I don't mind you wasting your *own* time, but I
> > do mind you wasting *other* people's time.
>
> > These things aren't difficult to get right. It's only a matter of
> > letting go of the time of *your* youth.
>
> > > He says the same thing everytime this comes up.
>
> > Of course. As long as fortran is around and being discussed, its
> > flaws must be addressed.
>
> > Rune
>
> I really enjoy reading the anti-FORTRAN flame wars here.

No flames in the anti-fortran discussions from my side.
It's usually enough to point out the facts. Suffice it
to say that such an obvious feature as dynamic memory
handling wasn't added to the language until the mid '90s,
some 40 years after the language was first developed.

Any flaming usually begins when some retired oldster who
has all the time in the world on his hand to mess around
with GOTO and hand 'optimization', and is too lazy to learn
what has been around since 1970, chimes in in order to maintain
his 'cool', 'youthful' self image for a nother few weeks...

Talking about fortran today is like talking about steam
engines to a mechanical engineer: It has a huge historical
significance, and might be worth being aware of for educational
and legacy purposes, but no one in their right mind would
even dream of basing a carreer on them. Or guide others in
that direction.

> Of the FORTRAN being written today, I wonder how much of it is simply adding features to legacy code and how much of it is new code, using all the bells and whistles added to it over the years to keep the name alive?

There are only two reasons to *code* fortran today:

1) Maintain legacy code
2) Because one is too lazy / outdated to know anything else

Rune

Subject: Learning Fortran

From: dpb

Date: 21 May, 2010 12:50:17

Message: 16 of 58

Rune Allnor wrote:
...

> No flames in the anti-fortran discussions from my side.
> It's usually enough to point out the facts. Suffice it
> to say that such an obvious feature as dynamic memory
> handling wasn't added to the language until the mid '90s,
> some 40 years after the language was first developed.
...

But the point is it has been as has much else and your arguments and
"facts" are based on 30+ yr-old "data".

--

Subject: Learning Fortran

From: dpb

Date: 21 May, 2010 12:55:55

Message: 17 of 58

Steve Amphlett wrote:
...

> I really enjoy reading the anti-FORTRAN flame wars here. Of the FORTRAN
> being written today, I wonder how much of it is simply adding features
> to legacy code and how much of it is new code, using all the bells and
> whistles added to it over the years to keep the name alive?

In comp.lang.fortran, certainly a high percentage of threads are on new
features by folks writing new code although much of what I know they're
working on is long-term applications. Others don't provide sufficient
background to know for certain the overall history of the code base
under development.

--

Subject: Learning Fortran

From: Rune Allnor

Date: 21 May, 2010 13:12:04

Message: 18 of 58

On 21 Mai, 14:50, dpb <n...@non.net> wrote:
> Rune Allnor wrote:
>
> ...
>
> > No flames in the anti-fortran discussions from my side.
> > It's usually enough to point out the facts. Suffice it
> > to say that such an obvious feature as dynamic memory
> > handling wasn't added to the language until the mid '90s,
> > some 40 years after the language was first developed.
>
> ...
>
> But the point is it has been as has much else and your arguments and
> "facts" are based on 30+ yr-old "data".

The language is a hoch-poch of features ad hoc stuck together
with string and rubber bands. That's the present-day fact.

Compare it to a only sligthly younger language, C++, itself
somewhere around 30 years old based on C, which is another
10 years older. C++ allows the programmer to not change the
*language*, which is standardized, but by adding *libraries*.
The skilled C++ programmers are able to essentially develop
their own, application-specific, languages, that easily run
way faster than anything fortran has to offer.

The present trend in programming is to write human-understandable
code. Only amateurs and fools think that source code is written
once, never to be seen by human eyes again. The fact of life
is that source code that was never intended as anything but
a one-off is copied, amended, changed, and even evolves into
huge systems. I can't find the references off the top of my
head, but I have seen some claims that both the C programming
language and the UNIX operating system started out the same
was as MS-DOS and later windows; as quick'n dirty ad hoc hacks
intended to just get something going.

This is how the world *actually* works. The code snippet one hacks
up today might be the basis for something you or somebody else
expands on years from now.

Accept that fact, and learn how to program accordingly.

Forgetting all about fortran (except what PITA it is to work with)
is a significant first step in that direction.

Rune

Subject: Learning Fortran

From: dpb

Date: 21 May, 2010 13:33:47

Message: 19 of 58

Rune Allnor wrote:
> On 21 Mai, 14:50, dpb <n...@non.net> wrote:
>> Rune Allnor wrote:
>>
>> ...
>>
>>> No flames in the anti-fortran discussions from my side.
>>> It's usually enough to point out the facts. Suffice it
>>> to say that such an obvious feature as dynamic memory
>>> handling wasn't added to the language until the mid '90s,
>>> some 40 years after the language was first developed.
>> ...
>>
>> But the point is it has been as has much else and your arguments and
>> "facts" are based on 30+ yr-old "data".
>
> The language is a hoch-poch of features ad hoc stuck together
> with string and rubber bands. That's the present-day fact.
>
> Compare it to a only sligthly younger language, C++, itself
> somewhere around 30 years old based on C, which is another
> 10 years older. C++ allows the programmer to not change the
> *language*, which is standardized, but by adding *libraries*.
> The skilled C++ programmers are able to essentially develop
> their own, application-specific, languages, that easily run
> way faster than anything fortran has to offer.
>
> The present trend in programming is to write human-understandable
> code. Only amateurs and fools think that source code is written
> once, never to be seen by human eyes again. The fact of life
> is that source code that was never intended as anything but
> a one-off is copied, amended, changed, and even evolves into
> huge systems. I can't find the references off the top of my
> head, but I have seen some claims that both the C programming
> language and the UNIX operating system started out the same
> was as MS-DOS and later windows; as quick'n dirty ad hoc hacks
> intended to just get something going.
>
> This is how the world *actually* works. The code snippet one hacks
> up today might be the basis for something you or somebody else
> expands on years from now.
>
> Accept that fact, and learn how to program accordingly.
>
> Forgetting all about fortran (except what PITA it is to work with)
> is a significant first step in that direction.
>
> Rune

There are arguments between the details of specifications of language
Standards as the shortcomings of current and proposed Fortran vis a vis
C++ and other languages at clf fairly regularly and there are issues on
both sides that have their own winners and losers.

I don't believe there's any way one can make such generic claims of
superiority of either. Certainly there's no reason one can not write at
least as easily and probably more so human-readable Fortran as C++ -- it
has all the structured programming constructs of the other; it is again
that you're still ranting against the FORTRAN of F66 or thereabouts as
opposed to that of today.

--

Subject: Learning Fortran

From: Rune Allnor

Date: 21 May, 2010 14:04:21

Message: 20 of 58

On 21 Mai, 15:33, dpb <n...@non.net> wrote:

> I don't believe there's any way one can make such generic claims of
> superiority of either.  

No one have talked about *superiority*. What I have said
is that fortran is *inferior* as it has been obsolete for
the past 40 years.

Rune

Subject: Learning Fortran

From: Steve Amphlett

Date: 21 May, 2010 14:37:06

Message: 21 of 58

Rune Allnor <allnor@tele.ntnu.no> wrote in message <eaee413f-f239-4b17-b427-b5bc571eb8f1@v37g2000vbv.googlegroups.com>...
> On 21 Mai, 15:33, dpb <n...@non.net> wrote:
>
> > I don't believe there's any way one can make such generic claims of
> > superiority of either.  
>
> No one have talked about *superiority*. What I have said
> is that fortran is *inferior* as it has been obsolete for
> the past 40 years.
>
> Rune

Hmm, I can only give a 30-year history myself, but this is the order I learned the mainstream languages (and used them for real work):

BASIC
Assembler
C
FORTRAN
C++

Matlab comes in between Assembler and C. Learning FORTRAN (out of necessity for using some simulation package) was a real chore. I still use C, C++ daily and FORTRAN for some projects (extending existing FORTRAN codes). I must admit, I've never written a MEX file using either FORTRAN or C++.

Subject: Learning Fortran

From: dpb

Date: 21 May, 2010 14:42:46

Message: 22 of 58

Rune Allnor wrote:
> On 21 Mai, 15:33, dpb <n...@non.net> wrote:
>
>> I don't believe there's any way one can make such generic claims of
>> superiority of either.
>
> No one have talked about *superiority*. What I have said
> is that fortran is *inferior* as it has been obsolete for
> the past 40 years.

But for that to be so means you can only talk about 40-yr old FORTRAN
and that is _NOT_ Fortran.

"Inferior/superior" is, in this instance, in the eye of the beholder
methinks... :)

--

Subject: Learning Fortran

From: Walter Roberson

Date: 21 May, 2010 14:54:29

Message: 23 of 58

Rune Allnor wrote:
> On 21 Mai, 15:33, dpb <n...@non.net> wrote:
>
>> I don't believe there's any way one can make such generic claims of
>> superiority of either.
>
> No one have talked about *superiority*. What I have said
> is that fortran is *inferior* as it has been obsolete for
> the past 40 years.

Oh, nonsense! 40 years ago was 1970, just 4 years after the release of
FORTRAN66, and before the large language upgrade of Fortran77.

C and C++ both have goto. You don't have to use goto in C or C++ if you
do not want to, and you do not have to use goto in any fortran from
Fortran77 onwards.

Subject: Learning Fortran

From: Jim

Date: 21 May, 2010 15:00:23

Message: 24 of 58

Rune Allnor <allnor@tele.ntnu.no> wrote in message <73d8e77f-b3ed-41b0-b684-da829e485ff5@c7g2000vbc.googlegroups.com>...
> Compare it to a only sligthly younger language, C++, itself
> somewhere around 30 years old based on C, which is another
> 10 years older. C++ allows the programmer to not change the
> *language*, which is standardized, but by adding *libraries*.
> The skilled C++ programmers are able to essentially develop
> their own, application-specific, languages, that easily run
> way faster than anything fortran has to offer.
>
> The present trend in programming is to write human-understandable
> code. Only amateurs and fools think that source code is written
> once, never to be seen by human eyes again. The fact of life
> is that source code that was never intended as anything but
> a one-off is copied, amended, changed, and even evolves into
> huge systems. I can't find the references off the top of my
> head, but I have seen some claims that both the C programming
> language and the UNIX operating system started out the same
> was as MS-DOS and later windows; as quick'n dirty ad hoc hacks
> intended to just get something going.
Just a little interjection to disambiguate few things:

- FORTRAN was created in the 1950s, and along with Ada is considered one of the initial programming languages. Earliest date on can find on a FORTRAN compiler is 1955, but since lack of clear and consistent documentation hasn't changed since the dawn of computing, that's probably an estimate.

- The C compiler was created by Brian Kernighan during the UNIX development project, in order to help him, Dennis Ritche, Weinberger and a host of others on their team more rapidly develop the OS itself. C's official birth year is marked as 1972, while the first official UNIX release has a date of 1974.

- C++ was created in the early 1980s and was initially just a pre-processor that would translate all of the code into C code using macros and pragmas, etc. There are various folks who argue the official birthdate of C++ due to this (since later there was a specific C++ compiler that wasn't just a pre-processor), wading into that pool seems pointless to me personally, but feel free to investigate it further if it floats your boat.


The primary complaint about the pre-procedural languages (starting with first Pascal and then C) are their lack of adequate scoping rules. With procedural (or functional) languages, one gained the ability to limit the scope of variables and was able to create a subroutine which could be called and then reliably return to the point of origin. The problem with goto and label is not only could one jump around to any particular point, but you could come *from* any particular point. The "return" effectively solved this problem. Moreover, the fact that every variable in early languages was global (FORTAN, Ada, COBOL, etc.) meant that it was extremely easy to screw up one's own logic, or someone else's by accident. Local variables resolved this problem as well.

To my knowledge the only "language" which actually fully supported (and even encouraged) altering the language itself remains Lisp, and its offspring. The things one can do with the lamba construct would probably make most programmers dizzy.


If that's useful, you're welcome. Otherwise, I'd rather not wade any further or deeper into some sort of religious language war.


Have a good day!
Jim

Subject: Learning Fortran

From: Baalzamon

Date: 25 May, 2010 10:50:08

Message: 25 of 58

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.
2) There are goto jumps, including the much tricksome (for a complete newcomer such as myself) 'computed?' goto.
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.
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.
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...then when we arrive at '85' do we ignore it or execture also?
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?

Subject: Learning Fortran

From: Rune Allnor

Date: 25 May, 2010 12:12:41

Message: 26 of 58

On 25 Mai, 12:50, "Baalzamon " <baalzamon_mori...@yahoo.com> 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

Subject: Learning Fortran

From: dpb

Date: 25 May, 2010 14:07:18

Message: 27 of 58

Baalzamon wrote:
...
> 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 one
> calls another, which calls another, which calls another etc.

Yes, Rune's got this part right w/o editorializing...

> 2) There are goto jumps, including the much tricksome (for a complete
> newcomer such as myself) 'computed?' goto.

Only because it's a construct you're not familiar with...it has a
specific syntax

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

That is a potential problem w/ any code no matter what the language, of
course...that's a function of the coder, not the language.

...

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

It's possible there's a code bug; more likely you missed the previous
definition/assignment of y. Perhaps it's in COMMON?



> 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
> immediately after the if statement...then when we arrive at '85' do we
> ignore it or execute also?

Yes, if the branch is not taken, code sequence "falls through" to the
next statement in sequence. Rune's "unless" is, while true, sort of a
red herring -- the rules are the same as you continue irregardless.

The target branch is the statement w/ the target label (85 in your
example here) and that statement is the next one executed if the branch
is taken; that is, the labeled statement is the target, not the line
succeeding the label.

      if(a. eq. 1) go to 85
        some code
   85 continue
      more code

is the same as

if(a .ne. 1) then
   some code
endif
more code

If the line "more code" had the label instead of a CONTINUE, the result
would be the same; that is you can always insert a CONTINUE line w/ the
label in front of the code line to aid in visualization if desired.

An IF...THEN...ELSE...ENDIF is constructed in a similar fashion as the
above IF...ENDIF by the use of a GOTO a second label beyond the desired
code of the ELSE block. With a little time, you'll begin to recognize
these idioms as you see them.

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

Yes, that's correct. The only missing action is that if L is outside
the range of [1,2] then execution will continue w/ the statement
following the GOTO statement

 From a Fortran language syntax manual...

> When the computed GO TO statement is executed, the expression is
evaluated first. The value of the expression represents the ordinal
position of a label in the associated list of labels. Control is
transferred to the statement identified by the label. For example, if
the list contains (30,20,30,40) and the value of the expression is 2,
control is transferred to the statement identified with label 20.
>
> If the value of the expression is less than 1 or greater than the
> number of labels in the list, control is transferred to the next
> executable statement or construct following the computed GO TO
> statement


Just to make Rune's day, I'll note that the computed GOTO was made
obsolescent by the F95 Standard. I'm not sure whether F2003 actually
then moved it to the deleted features list or not...

But, you'll not find a current compiler that doesn't support it although
it can be flagged by a compiler switch that checks for a given level of
Standard conformance.

I'll ask again...did you look at the tools (specifically Understand for
Fortran) at <www.scitools.com> for the trial download to aid in the
task? If not it or some of the open source tools of a similar nature
you're shortchanging yourself and making it more difficult than it needs be.

I'll also reiterate the suggestion to bring the Fortran-specific
questions to the Fortran group instead of cs-sm. That would be
comp.lang.fortran accessible from any newsreader pointing at one of the
free usenet mirror sites or via the Google Groups interface.

--

Subject: Learning Fortran

From: Walter Roberson

Date: 25 May, 2010 14:11:09

Message: 28 of 58

Baalzamon wrote:
> 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...then when we arrive at '85' do we
> ignore it or execture also?

Yes, if a is not 1 then the flow continues with the next executable
line. If 85 is ever reached then it will be executed. There is no
internal record kept of which branches have occurred.

> Go to (15,25), L
> DOes this mean depending upon the values of 'L' jump to 15 or 25?

Yes.

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

Yes.

Computed GOTOs were discouraged in Fortran starting with Fortran77. None
the less, in most languages that support some sort of switch statement,
the switch cases must be constants, and in the case where the values are
sequential, the program will end up internally executing something like
a computed GOTO. The _functionality_ of computed GOTOs is thus still
very much alive, but the _syntax_ of computed GOTOs is not.

Subject: Learning Fortran

From: Walter Roberson

Date: 25 May, 2010 14:16:41

Message: 29 of 58

Baalzamon wrote:
> 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...then when we arrive at '85' do we
> ignore it or execture also?

Yes, if a is not 1 then the flow continues with the next executable
line. If 85 is ever reached then it will be executed. There is no
internal record kept of which branches have occurred.

> Go to (15,25), L
> DOes this mean depending upon the values of 'L' jump to 15 or 25?

Yes.

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

Yes.

Computed GOTOs were discouraged in Fortran starting with Fortran77. None
the less, in most languages that support some sort of switch statement,
the switch cases must be constants, and in the case where the values are
sequential, the program will end up internally executing something like
a computed GOTO. The _functionality_ of computed GOTOs is thus still
very much alive, but the _syntax_ of computed GOTOs is not.

Subject: Learning Fortran

From: Steve Amphlett

Date: 25 May, 2010 14:36:06

Message: 30 of 58

Walter Roberson <roberson@hushmail.com> wrote in message <eZQKn.10565$%u7.5758@newsfe14.iad>...
>
> Computed GOTOs were discouraged in Fortran starting with Fortran77. None
> the less, in most languages that support some sort of switch statement,
> the switch cases must be constants, and in the case where the values are
> sequential, the program will end up internally executing something like
> a computed GOTO. The _functionality_ of computed GOTOs is thus still
> very much alive, but the _syntax_ of computed GOTOs is not.

Computed GOTO is horrible. I once did something similar in assembler (my code modified the jump address on the fly, so the program changed its own flow). Unfortunately the program that puts my meals on the table is still based on one large computed GOTO.

Subject: Learning Fortran

From: Baalzamon

Date: 25 May, 2010 14:40:24

Message: 31 of 58

(sorry if this is a double post, I hit the wrong button)
Much thanks everybody for the helpful advice and comments. I shall investigate the fortran specfic site for further help.
Last couple of questions.
considering this loop,

DO 10 I=1, N
a(I)=b(I)/5
10 z(I)=a(I)**2
Is the statement at the end label a part of the loop, I much thought it is....
As for the y=x scenario, it seems that the structure of the fall throughs were confusing me.
Once agan thanks folks.

Subject: Learning Fortran

From: James Tursa

Date: 25 May, 2010 14:56:24

Message: 32 of 58

"Baalzamon " <baalzamon_moridin@yahoo.com> wrote in message <htgngo$3ig$1@fred.mathworks.com>...
>
> DO 10 I=1, N
> a(I)=b(I)/5
> 10 z(I)=a(I)**2
> Is the statement at the end label a part of the loop, I much thought it is....

Yes. The above is the same as:

a(1:N) = b(1:N) ./ 5;
z(1:N) = a(1:N) .^ 2;

James Tursa

Subject: Learning Fortran

From: Walter Roberson

Date: 25 May, 2010 15:39:17

Message: 33 of 58

Steve Amphlett wrote:
> Walter Roberson <roberson@hushmail.com> wrote in message
> <eZQKn.10565$%u7.5758@newsfe14.iad>...
>>
>> Computed GOTOs were discouraged in Fortran starting with Fortran77.
>> None the less, in most languages that support some sort of switch
>> statement, the switch cases must be constants, and in the case where
>> the values are sequential, the program will end up internally
>> executing something like a computed GOTO. The _functionality_ of
>> computed GOTOs is thus still very much alive, but the _syntax_ of
>> computed GOTOs is not.

> Computed GOTO is horrible. I once did something similar in assembler
> (my code modified the jump address on the fly, so the program changed
> its own flow). Unfortunately the program that puts my meals on the
> table is still based on one large computed GOTO.

"Jump tables" are still often used in generated code, as they offer
fixed-time processing of switch/case statements when the choices are
fixed and not too numerous. Pseudo-codely:

switch (event_type) {
   case BUTTON_DOWN: body1;
   case MOUSE_MOVEMENT: body2;
   case WINDOW_CLOSE: body3;
   case HALT_AND_CATCH_FIRE: body4;
}

might become something like

Jump_Table19[] = {&Label19_1, &Label19_2, &Label19_end, &Label19_3,
&Label19_4};
Load D8, event_type
Subtract D8, =BUTTON_DOWN
BranchIfLessThan0, Label19_end
LoadEffectiveAddress.Long A7, Jump_Table19[D8]
BranchRegister A7
Label19_1: body1; Branch Label19_end
Label19_2: body2; Branch Label19_end
Label19_3: body4; Branch Label19_end
Label19_4: body3;
Label19_end: No_Operation

Equivalent Fortran code:

GOTO (191, 192, 195, 193, 194), eventtype
191 body1
     GOTO 195
192 body2
     GOTO 195
193 body4
     GOTO 195
194 body3
195 CONTINUE


No functional difference in the assembly or machine code: the main
difference is that switch is easier for humans to read and code.

Subject: Learning Fortran

From: Rune Allnor

Date: 25 May, 2010 16:44:16

Message: 34 of 58

On 25 Mai, 17:39, Walter Roberson <rober...@hushmail.com> wrote:

> No functional difference in the assembly or machine code: the main
> difference is that switch is easier for humans to read and code.

And that in itself is the reason why *humans* should stick with
*human-readable* code.

Rune

Subject: Learning Fortran

From: Walter Roberson

Date: 25 May, 2010 17:22:42

Message: 35 of 58

Rune Allnor wrote:
> On 25 Mai, 17:39, Walter Roberson <rober...@hushmail.com> wrote:
>
>> No functional difference in the assembly or machine code: the main
>> difference is that switch is easier for humans to read and code.
>
> And that in itself is the reason why *humans* should stick with
> *human-readable* code.

Previously you wrote,
"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."

It was _not_ obsolete 40 years ago: it is in active use internally in
any high performance language, and every serious programmer should know
the concept and know how and when to employ it.

Human readable code is not the only criteria in programming:
circumstances can make performance more important than the ability of
the average reader to make sense of the code.

Equivalent programming is often used in state machines -- which are
often used for "transaction programming" and are often used for
programming graphic user interfaces.

What any particular person finds easy to read depends on the person's
experience; for example, LISP programmers swear by LISP, finding it
"easy to read" when others just see a lot of ))))) . Or was LISP too
"obsolete 40 years ago" ?

Speaking of 40 years ago: as I pointed out to you the other day, 40
years ago was 1970, just four years after the release of FORTRAN66 and 7
years before the release of Fortran77. 1970 was also 2 years before the
release of C, and 2 years before the first edition of The PASCAL User
Manual And Report, with the first mass market edition (the one everyone
knows) of the UMAR not until 1978. If I have tracked properly, 40 years
ago was also the first available mostly-complete implementation of
Algol68 (people didn't know how to implement some of the features of
Algol for about 5 years after they started being discussed.)

You like to throw around "obsolete for 40 years", but you have not
demonstrated a good grasp of the state of programming 40 years ago.
State-of-the-art programming 40 years ago was COBOL66, which (if memory
serves me correctly) did not even allow nested structures, and which
relied heavily on MODIFY statements to alter the meaning of code!

Subject: Learning Fortran

From: Rune Allnor

Date: 25 May, 2010 17:52:19

Message: 36 of 58

On 25 Mai, 19:22, Walter Roberson <rober...@hushmail.com> wrote:
> Rune Allnor wrote:
> > On 25 Mai, 17:39, Walter Roberson <rober...@hushmail.com> wrote:
>
> >> No functional difference in the assembly or machine code: the main
> >> difference is that switch is easier for humans to read and code.
>
> > And that in itself is the reason why *humans* should stick with
> > *human-readable* code.
>
> Previously you wrote,
> "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."
>
> It was _not_ obsolete 40 years ago: it is in active use internally in
> any high performance language, and every serious programmer should know
> the concept and know how and when to employ it.

No. The serious programmer should only know how to express his
ideas in a human-language-based compromise between human
languages and machine code. I do not disagree that these kinds
of things are important on the machine code level, but the only
humans that need to know about these things are the fery few
people who write compilers.

> Human readable code is not the only criteria in programming:
> circumstances can make performance more important than the ability of
> the average reader to make sense of the code.

Preformance is low down on the priority list: The main priority
is that people understand what the program does. *If* a program's
perfomance can be *measured* to the effect that it is too slow,
then yes, something might have to be done to improve performance.

But *only* when *measurements* indisputably show that the program
is too slow.

If that happens, chances are that one might well want to skip
fortran alltogether, and work direcly in assembler, and take
advantage of whatever idiosyncracies are relevant on the
platform at hand.

> Equivalent programming is often used in state machines -- which are
> often used for "transaction programming" and are often used for
> programming graphic user interfaces.
>
> What any particular person finds easy to read depends on the person's
> experience; for example, LISP programmers swear by LISP, finding it
> "easy to read" when others just see a lot of ))))) . Or was LISP too
> "obsolete 40 years ago" ?

I don't know. I have never seen lisp, except for the language someone
told me was based on lisp that is used to configure emacs.

> You like to throw around "obsolete for 40 years", but you have not
> demonstrated a good grasp of the state of programming 40 years ago.
> State-of-the-art programming 40 years ago was COBOL66, which (if memory
> serves me correctly) did not even allow nested structures, and which
> relied heavily on MODIFY statements to alter the meaning of code!

OK, Fortran might *actually* have been obsolete 39 or 41 years
ago; I take for granted that your memory regarding that aera is
better than mine. It doesn't matter. No one born in the last five
decades needs have anything whatsoever to do with fortran.

Rune

Subject: Learning Fortran

From: dpb

Date: 25 May, 2010 17:52:51

Message: 37 of 58

Baalzamon wrote:
> (sorry if this is a double post, I hit the wrong button)
> Much thanks everybody for the helpful advice and comments. I shall
> investigate the fortran specfic site for further help. Last couple of
> questions. considering this loop,
> DO 10 I=1, N
> a(I)=b(I)/5
> 10 z(I)=a(I)**2
> Is the statement at the end label a part of the loop, I much thought it
> is....
...

Yes, as noted earlier, the above is the same as if it were written

    DO 10 I=1, N
      a(I)=b(I)/5
      z(I)=a(I)**2
10 CONTINUE

--

Subject: Learning Fortran

From: dpb

Date: 25 May, 2010 18:08:39

Message: 38 of 58

James Tursa wrote:
> "Baalzamon " <baalzamon_moridin@yahoo.com> wrote in message
> <htgngo$3ig$1@fred.mathworks.com>...
>>
>> DO 10 I=1, N
>> a(I)=b(I)/5
>> 10 z(I)=a(I)**2
>> Is the statement at the end label a part of the loop, I much thought
>> it is....
>
> Yes. The above is the same as:
>
> a(1:N) = b(1:N) ./ 5;
> z(1:N) = a(1:N) .^ 2;
>
> James Tursa

Which is the same as

a(1:N) = b(1:N)/5.0
z(1:N) = a(1:N)^2

In F90 and later...

:)

Or, of course, if the arrays a and b are of size N then one can as in ML
dispense w/ the subscript range expressions as well.

--

Subject: Learning Fortran

From: Bruno Luong

Date: 25 May, 2010 18:30:26

Message: 39 of 58

dpb <none@non.net> wrote in message <hth3rh$baj$1@news.eternal-september.org>...

>
> Which is the same as
>
> a(1:N) = b(1:N)/5.0
> z(1:N) = a(1:N)^2
>

Woah, I haven't programmed Fortran for a while, but the syntax looks neat.

Bruno

Subject: Learning Fortran

From: dpb

Date: 25 May, 2010 18:47:53

Message: 40 of 58

Bruno Luong wrote:
...

> Woah, I haven't programmed Fortran for a while, but the syntax looks neat.

Neither has Rune, apparently... :)

(Where "a while" seems to be something now approaching half of his
"magic number" of 40 years :( )

--

Subject: Learning Fortran

From: James Tursa

Date: 25 May, 2010 19:41:05

Message: 41 of 58

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <hth502$rf2$1@fred.mathworks.com>...
> dpb <none@non.net> wrote in message <hth3rh$baj$1@news.eternal-september.org>...
>
> >
> > Which is the same as
> >
> > a(1:N) = b(1:N)/5.0
> > z(1:N) = a(1:N)^2
> >
>
> Woah, I haven't programmed Fortran for a while, but the syntax looks neat.
>
> Bruno

Modern Fortran is an array based language. In many respects very similar to MATLAB. Whole array assignments, array slicing using the colon : notation, using non-unit stepping in the array slicing notation, element-wise operations when using arrays with operators (* in Fortran is equivalent to .* in MATLAB, etc.), built-in support for matrix multiplication and dot products and sums, scientific functions operate on arrays element-wise, etc etc are all part of the language. Array slices passed to subroutines can effectively be passed by reference, even when the slice dimensions use non-unit stepping so the underlying data is non-contiguous. The programmer doesn't even have to deal with it in the subroutine, the underlying memory indexing is done by the compiler for you. No unnecessary data copying is done. Fortran pointers carry not only the address of the target but also the dimensions
and any non-unit stepping of the dimensions. Fortran pointers are automatically dereferenced when used in an array context and can be treated just like they were the original array (e.g, they can be passed directly to a routine expecting an array as input). Dynamically allocated variables can always be tested to see if they are currently allocated, and are automatically deallocated when they go out of scope, preventing memory leaks. And of course compiled code is very fast. For scientific programming and array manipulation it is quite nice.

For example, suppose A, B, and C are all 5x5 arrays. Is the following Fortran or MATLAB?

A = B + C;
A(2:3,3:5) = B(1:2,2:4) + sin(C(3:4,1:3));

Answer: Both.

James Tursa

Subject: Learning Fortran

From: Bruno Luong

Date: 25 May, 2010 19:55:25

Message: 42 of 58

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <hth94h$6m7$1@fred.mathworks.com>...
>
>
> For example, suppose A, B, and C are all 5x5 arrays. Is the following Fortran or MATLAB?
>
> A = B + C;
> A(2:3,3:5) = B(1:2,2:4) + sin(C(3:4,1:3));
>

Nice! Hey I might convert my C program to Fortran, using lowercase variable names though. LOL.

Bruno

Subject: Learning Fortran

From: Walter Roberson

Date: 25 May, 2010 20:01:08

Message: 43 of 58

Rune Allnor wrote:

> OK, Fortran might *actually* have been obsolete 39 or 41 years
> ago; I take for granted that your memory regarding that aera is
> better than mine. It doesn't matter. No one born in the last five
> decades needs have anything whatsoever to do with fortran.

What language were _you_ programming in 40 years ago, and how did you debug it?

What language were you programming in 30 years ago, even? And how did you
debug that?

Myself, I am not old enough to have been programming 40 years ago, but I took
to it fairly quickly about 35 years ago. I have a fair idea of what was
realistically commercially available 30 years ago, having worked on a variety
of government and high-tech projects (I worked for a consulting firm in that
time frame, and then for a telephony company.) 30 years ago, a good debugger
was considered to be one that disassembled the machine code into machine
mnemonics -- it beat the hex memory dump printouts common 35 years ago.

Subject: Learning Fortran

From: dpb

Date: 25 May, 2010 20:39:22

Message: 44 of 58

Walter Roberson wrote:
> Rune Allnor wrote:
>
>> OK, Fortran might *actually* have been obsolete 39 or 41 years
>> ago; I take for granted that your memory regarding that aera is
>> better than mine. It doesn't matter. No one born in the last five
>> decades needs have anything whatsoever to do with fortran.
>
> What language were _you_ programming in 40 years ago, and how did you
> debug it?

CSC version of FORTRAN IV for the Philco 2000, mostly, and feeling
blessed for that level as opposed to the Philco FORTRAN II-like
alternative or only machine code...

> What language were you programming in 30 years ago, even? And how did
> you debug that?

That would've mostly been the CDC FORTRANs then; I forget the time frame
of which version levels were when, precisely, w/ a little COMPASS for
good measure thrown in...

And, indeed debuggers weren't much of an option; it wasn't until not
much before the 30-yr ago mark there was even a single user-accessible
terminal to the Cyber-7600. Employer was commercial nuclear reactor
vendor; the 6600 replace the Philco subsequently upgraded to the 7600.

--

Subject: Learning Fortran

From: Luka Djigas

Date: 25 May, 2010 22:08:59

Message: 45 of 58

On Tue, 25 May 2010 10:52:19 -0700 (PDT), Rune Allnor <allnor@tele.ntnu.no> wrote:

>OK, Fortran might *actually* have been obsolete 39 or 41 years
>ago; I take for granted that your memory regarding that aera is
>better than mine. It doesn't matter. No one born in the last five
>decades needs have anything whatsoever to do with fortran.
>
>Rune

Upon reading something like this, my mind immediatelly wonders to the
immortal words of Charlie Brown and Abraham Lincoln;

"Good grief!" (Charlie Brown)

"It is better to be silent and be thought a fool than to speak and remove all doubt. "
(Lincoln)

-- Luka

Subject: Learning Fortran

From: Baalzamon

Date: 25 May, 2010 22:14:08

Message: 46 of 58

Ah I know i said i only had a couple more questions...but ....
I stumbled across something that told me that indices in arrays can be negative numbers; is this true? If so how does the 'mex' thingy cope with this? One of my options for my conversion is to, as someone pointed out previously, is to call the functions, subroutines etc straight from matlab. Which I shall implement but more as a timing experiment. The first priority is to convert the code.
This is one for the Fortran programmers. Could anyone explain, line by line, if possible the code for 'DAXPY'.
Why the need for unequal increments (and what does this mean)?
If I understand we are trying to work out z=Ax + y
where x and y are vectors. Thus I thought the situtations are
A=0 so z=y
A=1 so z=x+y
A=-1 so z=y-x
in theory these should be less calculations, as such faster to work out so check for this first.
Only situtaions that are left
A>1 or A<-1
As such why is the code not something like this?
DO 10 I=1, N
Z(I)=A*(x(I)) + y(I)
10 CONTINUE

Subject: Learning Fortran

From: James Tursa

Date: 25 May, 2010 23:13:24

Message: 47 of 58

"Baalzamon " <baalzamon_moridin@yahoo.com> wrote in message <hthi3g$347$1@fred.mathworks.com>...
> Ah I know i said i only had a couple more questions...but ....
> I stumbled across something that told me that indices in arrays can be negative numbers; is this true?

Yes. In Fortran you can set up the array indexing to have any range you want. However, based on your further comments I don't think this is the case for your example.

> If so how does the 'mex' thingy cope with this?

If the Fortran is written correctly no adjustment is necessary.

> One of my options for my conversion is to, as someone pointed out previously, is to call the functions, subroutines etc straight from matlab. Which I shall implement but more as a timing experiment. The first priority is to convert the code.
> This is one for the Fortran programmers. Could anyone explain, line by line, if possible the code for 'DAXPY'.

DAXPY is a BLAS routine. Please don't tell me you are converting a BLAS routine to MATLAB m-code! MATLAB already has a BLAS library you can call directly from a mex routine that implements all of the BLAS routines, including DAXPY. If you are just trying to understand what DAXPY does, then google "netlib daxpy" and click on the netlib link to see the source code with comments. Here is what the first section says for DAXPY:

      SUBROUTINE DAXPY(N,DA,DX,INCX,DY,INCY)
* .. Scalar Arguments ..
      DOUBLE PRECISION DA
      INTEGER INCX,INCY,N
* ..
* .. Array Arguments ..
      DOUBLE PRECISION DX(*),DY(*)
* ..
*
* Purpose
* =======
*
* constant times a vector plus a vector.

It is basically doing the calculation DY = DY + DA * DX. If you examine the code you find that the code allows for traversing the input vectors in either order (first-to-last or last-to-first) and with a non-unit step. That is what the INCX and INCY inputs are for. The same thing can be handled in m-code with the loops replaced with vector calculation using colon indexing. (btw, the same can be said for modern Fortran).

James Tursa

Subject: Learning Fortran

From: dpb

Date: 26 May, 2010 04:18:19

Message: 48 of 58

dpb wrote:
> James Tursa wrote:
>> "Baalzamon " <baalzamon_moridin@yahoo.com> wrote in message
>> <htgngo$3ig$1@fred.mathworks.com>...
>>>
>>> DO 10 I=1, N
>>> a(I)=b(I)/5
>>> 10 z(I)=a(I)**2
>>> Is the statement at the end label a part of the loop, I much thought
>>> it is....
>>
>> Yes. The above is the same as:
>>
>> a(1:N) = b(1:N) ./ 5;
>> z(1:N) = a(1:N) .^ 2;
>>
>> James Tursa
>
> Which is the same as
>
> a(1:N) = b(1:N)/5.0
> z(1:N) = a(1:N)^2
>
> In F90 and later...
>
> :)
>
> Or, of course, if the arrays a and b are of size N then one can as in ML
> dispense w/ the subscript range expressions as well.

Ooops...


 >> z(1:N) = a(1:N) .^ 2;

goes to

z(1:N) = a(1:N)**2

"**" is Fortran exponentiation operator, not "^" ...

--

Subject: Learning Fortran

From: us

Date: 26 May, 2010 06:48:04

Message: 49 of 58

"Baalzamon " <baalzamon_moridin@yahoo.com> wrote in message <ht36t0$dc8$1@fred.mathworks.com>...
> I am attempting to convert some old fortran codes and becoming somewhat annoyed by the apparent jumping of code. WOuld I be correct in assuming that the code is read top to bottom and in line number order? If so where does the do label numbers figure into this scheme? Any advice from fortan programmers would be appreciated. To be explicit I think the coxde was written in F77...

why not simply use ML's F interface(?)...

http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_external/f23224.html

us

Subject: Learning Fortran

From: dpb

Date: 26 May, 2010 12:11:55

Message: 50 of 58

James Tursa wrote:
> "Baalzamon " <baalzamon_moridin@yahoo.com> wrote in message
> <hthi3g$347$1@fred.mathworks.com>...
...

>> This is one for the Fortran programmers. Could anyone explain, line by
>> line, if possible the code for 'DAXPY'.
>
> DAXPY is a BLAS routine. Please don't tell me you are converting a BLAS
> routine to MATLAB m-code! ...
...
> * Purpose
> * =======
> *
> * constant times a vector plus a vector.
>
> It is basically doing the calculation DY = DY + DA * DX. If you examine
> the code you find that the code allows for traversing the input vectors
> in either order (first-to-last or last-to-first) and with a non-unit
> step. That is what the INCX and INCY inputs are for. The same thing can
> be handled in m-code with the loops replaced with vector calculation
> using colon indexing. (btw, the same can be said for modern Fortran).

And, I'll note that the vector notation of both Matlab and Fortran in
the source code will be turned into the same DO loop by the compilers
for execution and as would also be done by a C or Cpp or virtually any
other optimizing compiler language.

--

Subject: Learning Fortran

From: Walter Roberson

Date: 26 May, 2010 14:01:33

Message: 51 of 58

dpb wrote:

> And, I'll note that the vector notation of both Matlab and Fortran in
> the source code will be turned into the same DO loop by the compilers
> for execution and as would also be done by a C or Cpp or virtually any
> other optimizing compiler language.

Not if you are using a Single Instruction Multiple Data (SIMD)
architecture with a sufficiently wide data list. The Intel SSE3
architecture is SIMD (but not especially wide.)

Subject: Learning Fortran

From: Steve Amphlett

Date: 26 May, 2010 14:13:06

Message: 52 of 58

dpb <none@non.net> wrote in message <htj3ae$e9e$1@speranza.aioe.org>...
>
> And, I'll note that the vector notation of both Matlab and Fortran in
> the source code will be turned into the same DO loop by the compilers
> for execution and as would also be done by a C or Cpp or virtually any
> other optimizing compiler language.
>
> --


Matlab started out life as a wrapper around FORTRAN. Isn't it nice that FORTRAN is morphing into Matlab now?

Subject: Learning Fortran

From: dpb

Date: 26 May, 2010 14:19:29

Message: 53 of 58

Walter Roberson wrote:
> dpb wrote:
>
>> And, I'll note that the vector notation of both Matlab and Fortran in
>> the source code will be turned into the same DO loop by the compilers
>> for execution and as would also be done by a C or Cpp or virtually any
>> other optimizing compiler language.
>
> Not if you are using a Single Instruction Multiple Data (SIMD)
> architecture with a sufficiently wide data list. The Intel SSE3
> architecture is SIMD (but not especially wide.)

Well, yes, I left out multiple cores and such other hardware but the
point is that compilers will all generate essentially the same
instruction set for a similar set of operations (for a specific set of
hardware) irregardless of the source code format (as long as one uses
optimization switches and doesn't do specific tricks that prevent
optimizations). Essentially the same thing w/ loops as you pointed out
earlier about jump tables and switching constructs--it all has to
translate back to the instruction set and what's effective there is
dependent on the hardware and instruction set available, number of
registers, etc., etc., etc., ... So, not surprisingly, whatever the
source form, similar constructs end up being implemented in similar
fashion whatever the language.

Way back on the CDC, there was loop unrolling and automagic
parallelization of DO loops to take advantage of the installed hardware.
Any given machine had it's own number of vector registers (depending on
how deep the customer's pockets were :) ). Have cousin who worked for
CDC in MN in support of the FTN compilers. A task was to modify to
match the hardware for the various installations.

The point is for folks to not get so bound up in what the source
language is...

--

Subject: Learning Fortran

From: dpb

Date: 26 May, 2010 21:04:30

Message: 54 of 58

Steve Amphlett wrote:
> dpb <none@non.net> wrote in message <htj3ae$e9e$1@speranza.aioe.org>...
>>
>> And, I'll note that the vector notation of both Matlab and Fortran in
>> the source code will be turned into the same DO loop by the compilers
>> for execution and as would also be done by a C or Cpp or virtually any
>> other optimizing compiler language.
>>
>> --
>
>
> Matlab started out life as a wrapper around FORTRAN. Isn't it nice that
> FORTRAN is morphing into Matlab now?

Yes, indeed, altho I think there are limitations owing to compatibility
that will limit the progression. The biggest difference will, I think,
continue to be that won't be able to overload operators to make things
like "*" be matrix multiply so will either have to write own generic
interfaces for cases where can and not sure how far one can actually go
in that regards.

But, it is certainly "not your father's FORTRAN" any longer, for sure. :)

--

Subject: Learning Fortran

From: James Tursa

Date: 26 May, 2010 22:33:22

Message: 55 of 58

dpb <none@non.net> wrote in message <htk2h9$4rg$1@news.eternal-september.org>...
>
> The biggest difference will, I think,
> continue to be that won't be able to overload operators to make things
> like "*" be matrix multiply so will either have to write own generic
> interfaces for cases where can and not sure how far one can actually go
> in that regards.

Yes, you can't overload "*" to be matrix multiply for built-in type arrays like arrays of real, but you can overload "*" to be a matrix multiply for a user-defined type, and you can always create a brand new operator to do a matrix multiply so you could write something like A.mmult.B to get a matrix multiply for real types A and B. In defense I would note that other OOP languages like C++ don't allow overloading the built-in operators for intrinsic types either.

James Tursa

Subject: Learning Fortran

From: dpb

Date: 27 May, 2010 13:21:03

Message: 56 of 58

James Tursa wrote:
> dpb <none@non.net> wrote in message
> <htk2h9$4rg$1@news.eternal-september.org>...
>>
>> The biggest difference will, I think, continue to be that won't be
>> able to overload operators to make things like "*" be matrix multiply
>> so will either have to write own generic interfaces for cases where
>> can and not sure how far one can actually go in that regards.
>
> Yes, you can't overload "*" to be matrix multiply for built-in type
> arrays like arrays of real, but you can overload "*" to be a matrix
> multiply for a user-defined type, and you can always create a brand new
> operator to do a matrix multiply so you could write something like
> A.mmult.B to get a matrix multiply for real types A and B. In defense I
> would note that other OOP languages like C++ don't allow overloading the
> built-in operators for intrinsic types either.

Wasn't intended as criticism or as disparaging Fortran vis a vis
alternative existing languages, simply commenting to Stephen's
observation on the morphing of Fortran towards Matlab re: array
operations that there's not a way to make that as seamless as it is in
ML simply owing to the limitations of existing syntax (at a bare minimum).

--

Subject: Learning Fortran

From: Steve Amphlett

Date: 27 May, 2010 14:33:10

Message: 57 of 58

dpb <none@non.net> wrote in message <htlrob$mrn$1@news.eternal-september.org>...
> Wasn't intended as criticism or as disparaging Fortran vis a vis
> alternative existing languages, simply commenting to Stephen's
> observation on the morphing of Fortran towards Matlab re: array
> operations that there's not a way to make that as seamless as it is in
> ML simply owing to the limitations of existing syntax (at a bare minimum).

Maybe it's veering tpwards BASIC? I remember doing (complex) matrix operations in HP Instrument BASIC 15 years ago.

Subject: Learning Fortran

From: dpb

Date: 27 May, 2010 18:03:03

Message: 58 of 58

Steve Amphlett wrote:
> dpb <none@non.net> wrote in message
> <htlrob$mrn$1@news.eternal-september.org>...
>> Wasn't intended as criticism or as disparaging Fortran vis a vis
>> alternative existing languages, simply commenting to Stephen's
>> observation on the morphing of Fortran towards Matlab re: array
>> operations that there's not a way to make that as seamless as it is in
>> ML simply owing to the limitations of existing syntax (at a bare
>> minimum).
>
> Maybe it's veering tpwards BASIC? I remember doing (complex) matrix
> operations in HP Instrument BASIC 15 years ago.

HP-BASIC (and the shortlived TBASIC clone) are the only instances of
BASIC that I'm aware of that ever supported complex. Of course, it had
all kinds of other extensions as well HPIB control, embedded graphics,
etc., etc., ... I did quite a number of systems on the HP-85 and other
"desktops" like the 9845, etc. I recall one system for a DOE
application had nearly $1M invested in the system w/ the computer,
9-track tape, standalone hard-disk drive and a 3582A spectrum analyzer.
  One could spend some serious money in a hurry when opening up the HP
(or Tektronix). I forget the name of the instrumentation wideband
analog tape drive; that puppy wasn't cheap, either... :)

Fortran has passed any dialect of Basic I know in array operations w/
F90--there were almost no array operations in Visual Basic (Classic,
I've not looked at the .Net versions which really did change quite a lot
altho I don't think in that regard; more in the object-ness and
net-centric manner and more towards C# flavor than F90+).

--

Tags for this Thread

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us