Thread Subject: goto, again

I have this routine in Fortran


      do m1=2,n
         m1m(m1) = 1
         do j=m1-1,2,-1
            if (x(j).ne.x(j-1)) then
               m1m(m1) = j
               goto 441
            endif
         enddo
 441 continue
      enddo

that is part of a larger code.
I converted it in Matlab as

for m1=2:n;
    m1m(m1) = 1;
    for j=m1-1:-1:2;
        if(x(j)~=x(j-1)) ;
            m1m(m1) = j;
            continue;
        end;
    end;
end;

of course the results are not the same, and this is due to
my inabilty to translate the goto function
How can I solve this problem?

"Armando Ciccarelli" <damagedlemon@gmail.com> wrote in
message <g3vjsl$asv$1@fred.mathworks.com>...
> I have this routine in Fortran
>
>
> do m1=2,n
> m1m(m1) = 1
> do j=m1-1,2,-1
> if (x(j).ne.x(j-1)) then
> m1m(m1) = j
> goto 441
> endif
> enddo
> 441 continue
> enddo
>
> that is part of a larger code.
> I converted it in Matlab as
>
> for m1=2:n;
> m1m(m1) = 1;
> for j=m1-1:-1:2;
> if(x(j)~=x(j-1)) ;
> m1m(m1) = j;
> continue;
> end;
> end;
> end;
>
> of course the results are not the same, and this is due
to
> my inabilty to translate the goto function
> How can I solve this problem?

Use Matlab as designed. Your double nested loop can
probably be done with a single Matlab line. If you state
your original problem you may find some kind person shows
you the light (I personally can't be arsed to plough
through all that Fortran).

I have a matrix: x
I want to make a matrix m1m from it, based on the following
rules.

For example, [......] would give [.......]

"Steve Amphlett" <Firstname.Lastname@Where-I-Work.com> wrote in
message <g3vl26$khl$1@fred.mathworks.com>...
> "Armando Ciccarelli" <damagedlemon@gmail.com> wrote in
> message <g3vjsl$asv$1@fred.mathworks.com>...
> > I have this routine in Fortran
> >
> >
> > do m1=2,n
> > m1m(m1) = 1
> > do j=m1-1,2,-1
> > if (x(j).ne.x(j-1)) then
> > m1m(m1) = j
> > goto 441
> > endif
> > enddo
> > 441 continue
> > enddo
> >
> > that is part of a larger code.
> > I converted it in Matlab as
> >
> > for m1=2:n;
> > m1m(m1) = 1;
> > for j=m1-1:-1:2;
> > if(x(j)~=x(j-1)) ;
> > m1m(m1) = j;
> > continue;
> > end;
> > end;
> > end;
> >
> > of course the results are not the same, and this is due
> to
> > my inabilty to translate the goto function
> > How can I solve this problem?
>
> Use Matlab as designed. Your double nested loop can
> probably be done with a single Matlab line. If you state
> your original problem you may find some kind person shows
> you the light (I personally can't be arsed to plough
> through all that Fortran).
>
> I have a matrix: x
> I want to make a matrix m1m from it, based on the following
> rules.
>
> For example, [......] would give [.......]

That was an example of Fortran code for which
the author should be shot. It is what (rightfully
so, IMHO) gave fortran such a bad name.

A complete lack of comments. Use of variable
names like m1m and m1. goto. (shiver)

I find it interesting that Steve was unwilling to
read through such a tiny code fragment. Bad
code does this to you. The answer is truly to
understand what the code does, and then to
write that in Matlab, rather than perpetuating
such a poorly written piece of code. Had the
code actually had comments that explained
the purpose of this fragment, this might have
been much simpler.

Ok, I'm through venting.

set('JohnsRoot','RantMode','off')

The outer loop looks at each element of x,
sequentially, from the second to the end.
The inner loop finds the first index, working
backwards, such that x(j) ~= x(j-1).

So you might figure out how to do this, or
perhaps figure out why the author is trying
to form this result in the first place. Or you
can just use break instead of continue.

John

"John D'Errico" <woodchips@rochester.rr.com> wrote in
message <g3vt8l$r5h$1@fred.mathworks.com>...
> "Steve Amphlett" <Firstname.Lastname@Where-I-Work.com>
wrote in
> message <g3vl26$khl$1@fred.mathworks.com>...
> > "Armando Ciccarelli" <damagedlemon@gmail.com> wrote in
> > message <g3vjsl$asv$1@fred.mathworks.com>...
> > > I have this routine in Fortran
> > >
> > >
> > > do m1=2,n
> > > m1m(m1) = 1
> > > do j=m1-1,2,-1
> > > if (x(j).ne.x(j-1)) then
> > > m1m(m1) = j
> > > goto 441
> > > endif
> > > enddo
> > > 441 continue
> > > enddo
> > >
> > > that is part of a larger code.
> > > I converted it in Matlab as
> > >
> > > for m1=2:n;
> > > m1m(m1) = 1;
> > > for j=m1-1:-1:2;
> > > if(x(j)~=x(j-1)) ;
> > > m1m(m1) = j;
> > > continue;
> > > end;
> > > end;
> > > end;
> > >
> > > of course the results are not the same, and this is due
> > to
> > > my inabilty to translate the goto function
> > > How can I solve this problem?
> >
> > Use Matlab as designed. Your double nested loop can
> > probably be done with a single Matlab line. If you state
> > your original problem you may find some kind person shows
> > you the light (I personally can't be arsed to plough
> > through all that Fortran).
> >
> > I have a matrix: x
> > I want to make a matrix m1m from it, based on the following
> > rules.
> >
> > For example, [......] would give [.......]
>
> That was an example of Fortran code for which
> the author should be shot. It is what (rightfully
> so, IMHO) gave fortran such a bad name.
>
> A complete lack of comments. Use of variable
> names like m1m and m1. goto. (shiver)
>
> I find it interesting that Steve was unwilling to
> read through such a tiny code fragment. Bad
> code does this to you. The answer is truly to
> understand what the code does, and then to
> write that in Matlab, rather than perpetuating
> such a poorly written piece of code. Had the
> code actually had comments that explained
> the purpose of this fragment, this might have
> been much simpler.
>
> Ok, I'm through venting.
>
> set('JohnsRoot','RantMode','off')
>
> The outer loop looks at each element of x,
> sequentially, from the second to the end.
> The inner loop finds the first index, working
> backwards, such that x(j) ~= x(j-1).
>
> So you might figure out how to do this, or
> perhaps figure out why the author is trying
> to form this result in the first place. Or you
> can just use break instead of continue.
>
> John


break instead of continue stops the inner loop, while the
option in the fortran code allows to exit both of the two loops.

i tried using break

what i get is a vector which has zero as first value, one as
second, then it takes the value of j such that x(j) and
x(j-1) are different: the value is carried over the
following elements of the vector until the inner cicle
doesn't find another value j such that x(j) and x(j-1) are
different: at this point the procedures begins again...

so it goes like

[0 1 2 2 2 2 2 3 3 3 3 3 3 4 4 4 10 10 10...], something
like that...

i am trying to understand, and i think this was the actual
intention of the author,wheter instead the vector should be
something like:

[0 1 2 1 1 1 1 3 1 1 1 1 1 4 1 1 10 1 1...], so that the
value j st x(j) doesnt equal x(j-1) is not carried over...

hope i made myself clear

"Armando Ciccarelli" <damagedlemon@gmail.com> wrote in
message <g40lmh$bdc$1@fred.mathworks.com>...
> "John D'Errico" <woodchips@rochester.rr.com> wrote in
> message <g3vt8l$r5h$1@fred.mathworks.com>...
> > "Steve Amphlett" <Firstname.Lastname@Where-I-Work.com>
> wrote in
> > message <g3vl26$khl$1@fred.mathworks.com>...
> > > "Armando Ciccarelli" <damagedlemon@gmail.com> wrote in
> > > message <g3vjsl$asv$1@fred.mathworks.com>...
> > > > I have this routine in Fortran
> > > >
> > > >
> > > > do m1=2,n
> > > > m1m(m1) = 1
> > > > do j=m1-1,2,-1
> > > > if (x(j).ne.x(j-1)) then
> > > > m1m(m1) = j
> > > > goto 441
> > > > endif
> > > > enddo
> > > > 441 continue
> > > > enddo
> > > >
> > > > that is part of a larger code.
> > > > I converted it in Matlab as
> > > >
> > > > for m1=2:n;
> > > > m1m(m1) = 1;
> > > > for j=m1-1:-1:2;
> > > > if(x(j)~=x(j-1)) ;
> > > > m1m(m1) = j;
> > > > continue;
> > > > end;
> > > > end;
> > > > end;
> > > >
> > > > of course the results are not the same, and this is due
> > > to
> > > > my inabilty to translate the goto function
> > > > How can I solve this problem?
> > >
> > > Use Matlab as designed. Your double nested loop can
> > > probably be done with a single Matlab line. If you state
> > > your original problem you may find some kind person shows
> > > you the light (I personally can't be arsed to plough
> > > through all that Fortran).
> > >
> > > I have a matrix: x
> > > I want to make a matrix m1m from it, based on the
following
> > > rules.
> > >
> > > For example, [......] would give [.......]
> >
> > That was an example of Fortran code for which
> > the author should be shot. It is what (rightfully
> > so, IMHO) gave fortran such a bad name.
> >
> > A complete lack of comments. Use of variable
> > names like m1m and m1. goto. (shiver)
> >
> > I find it interesting that Steve was unwilling to
> > read through such a tiny code fragment. Bad
> > code does this to you. The answer is truly to
> > understand what the code does, and then to
> > write that in Matlab, rather than perpetuating
> > such a poorly written piece of code. Had the
> > code actually had comments that explained
> > the purpose of this fragment, this might have
> > been much simpler.
> >
> > Ok, I'm through venting.
> >
> > set('JohnsRoot','RantMode','off')
> >
> > The outer loop looks at each element of x,
> > sequentially, from the second to the end.
> > The inner loop finds the first index, working
> > backwards, such that x(j) ~= x(j-1).
> >
> > So you might figure out how to do this, or
> > perhaps figure out why the author is trying
> > to form this result in the first place. Or you
> > can just use break instead of continue.
> >
> > John
>
>
> break instead of continue stops the inner loop, while the
> option in the fortran code allows to exit both of the two
loops.
>
> i tried using break
>
> what i get is a vector which has zero as first value, one as
> second, then it takes the value of j such that x(j) and
> x(j-1) are different: the value is carried over the
> following elements of the vector until the inner cicle
> doesn't find another value j such that x(j) and x(j-1) are
> different: at this point the procedures begins again...
>
> so it goes like
>
> [0 1 2 2 2 2 2 3 3 3 3 3 3 4 4 4 10 10 10...], something
> like that...
>
> i am trying to understand, and i think this was the actual
> intention of the author,wheter instead the vector should be
> something like:
>
> [0 1 2 1 1 1 1 3 1 1 1 1 1 4 1 1 10 1 1...], so that the
> value j st x(j) doesnt equal x(j-1) is not carried over...
>
> hope i made myself clear

the vector I refer to is m1m(m1)

"Armando Ciccarelli" <damagedlemon@gmail.com> wrote in
message <g3vjsl$asv$1@fred.mathworks.com>...
> I have this routine in Fortran
>
>
> do m1=2,n
> m1m(m1) = 1
> do j=m1-1,2,-1
> if (x(j).ne.x(j-1)) then
> m1m(m1) = j
> goto 441
> endif
> enddo
> 441 continue
> enddo
>

Hi,
Unless I tried to understand your code, this could work:

> for m1=2:n;
> m1m(m1) = 1;
> for j=m1-1:-1:2;
> if(x(j)~=x(j-1)) ;
> m1m(m1) = j;
> break2 = true;
> break;
> end;
> if break2, break, end
> end;
> if break2, break, end
> end;

I hope this works.

Mira

"Armando Ciccarelli" <damagedlemon@gmail.com> wrote in
message <g40lmh$bdc$1@fred.mathworks.com>...
>
>
> break instead of continue stops the inner loop, while the
> option in the fortran code allows to exit both of the
two loops.
>
> i tried using break
>
> what i get is a vector which has zero as first value,
one as
> second, then it takes the value of j such that x(j) and
> x(j-1) are different: the value is carried over the
> following elements of the vector until the inner cicle
> doesn't find another value j such that x(j) and x(j-1)
are
> different: at this point the procedures begins again...
>
> so it goes like
>
> [0 1 2 2 2 2 2 3 3 3 3 3 3 4 4 4 10 10 10...], something
> like that...
>
> i am trying to understand, and i think this was the
actual
> intention of the author,wheter instead the vector should
be
> something like:
>
> [0 1 2 1 1 1 1 3 1 1 1 1 1 4 1 1 10 1 1...], so that the
> value j st x(j) doesnt equal x(j-1) is not carried
over...
>
> hope i made myself clear

I (and maybe others) are still not clear what you are
trying to do here. If you just want to translate the
Fortran code into MATLAB as directly as possible, then
just replace your "continue" with "break" as John has
already suggested, and that will do it. The Fortran code
and the MATLAB code will produce the same answer. That
immediate problem should be solved. (As another poster has
pointed out, however, this does not directly solve other
GOTO problems for breaking out of multiple loops).

What is your last comment about? Are you implying that the
Fortran code is not correct and needs to be changed? How
can we help with that if we don't even know what the
context is or what problem is being solved? Why do you
think it is wrong? Please clarify this.

With regards to John's rants on the Fortran programming
style for this particular piece of code, most of it is
well taken. However, remember that back in the early days
Fortran only had 6 characters available for variable
names, there was no "while" construct available in the
language, and there was no "remainder of line are
comments" capability. The *only* way to break out of a
loop was to use a GOTO statement with an associated label
on another statement (usually a CONTINUE). Modern Fortran
has fixed these and other shortcomings, of course, but
there's billions of lines of Fortran out there that people
will be tapping into for generations and much of it was
written during the early years. Have *some* pity on the
original programmers and don't curse them too much when
the free piece of code they have given you is a bit ugly.

James Tursa

"James Tursa" <aclassyguywithaknotac@hotmail.com> wrote in message
<g412h5$h7t$1@fred.mathworks.com>...
> With regards to John's rants on the Fortran programming
> style for this particular piece of code, most of it is
> well taken. However, remember that back in the early days
> Fortran only had 6 characters available for variable
> names, there was no "while" construct available in the
> language, and there was no "remainder of line are
> comments" capability. The *only* way to break out of a
> loop was to use a GOTO statement with an associated label
> on another statement (usually a CONTINUE). Modern Fortran
> has fixed these and other shortcomings, of course, but
> there's billions of lines of Fortran out there that people
> will be tapping into for generations and much of it was
> written during the early years. Have *some* pity on the
> original programmers and don't curse them too much when
> the free piece of code they have given you is a bit ugly.
>
> James Tursa

James - as someone who came from a fortran
background, and learned to code spaghetti
with/from the very "best" spaghetti coders,
I do recognize the source of these problems.

I also reserve the right to try to convince others
of the error of these ways. Even new fortran
code often has the same flaws, even though
there are now better constructs to be found
in the new fortran versions. When your mentors
write crap for code, you will learn to reproduce
that behavior. The crap propagates, and will do
so forever unless we show there is a better way.
(Do memes exist in programming? I think so.)

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

John

"John D'Errico" <woodchips@rochester.rr.com> wrote in
message <g41p4t$ptf$1@fred.mathworks.com>...
> "James Tursa" <aclassyguywithaknotac@hotmail.com> wrote
in message
> <g412h5$h7t$1@fred.mathworks.com>...
> > With regards to John's rants on the Fortran programming
> > style for this particular piece of code, most of it is
> > well taken. However, remember that back in the early
days
> > Fortran only had 6 characters available for variable
> > names, there was no "while" construct available in the
> > language, and there was no "remainder of line are
> > comments" capability. The *only* way to break out of a
> > loop was to use a GOTO statement with an associated
label
> > on another statement (usually a CONTINUE). Modern
Fortran
> > has fixed these and other shortcomings, of course, but
> > there's billions of lines of Fortran out there that
people
> > will be tapping into for generations and much of it was
> > written during the early years. Have *some* pity on the
> > original programmers and don't curse them too much when
> > the free piece of code they have given you is a bit
ugly.
> >
> > James Tursa
>
> James - as someone who came from a fortran
> background, and learned to code spaghetti
> with/from the very "best" spaghetti coders,
> I do recognize the source of these problems.
>
> I also reserve the right to try to convince others
> of the error of these ways. Even new fortran
> code often has the same flaws, even though
> there are now better constructs to be found
> in the new fortran versions. When your mentors
> write crap for code, you will learn to reproduce
> that behavior. The crap propagates, and will do
> so forever unless we show there is a better way.
> (Do memes exist in programming? I think so.)
>
> http://en.wikipedia.org/wiki/Meme
>
> John

I was expecting to be flamed by the OP and others for my
off-hand profanity and lack of tangible help. But I
wasn't, so I'll dig my hole a bit deeper.

We have a lot of requests here for converting terse and
instantly understandable ML code into C, C++ or Fortran.
They are understandable - many algorithms are prototyped in
ML, in my view the best enviroment available for this sort
of thing. C or Fortran code to do what ML can do in one
line is always going to be a lot bigger, loopy and not
instantly obvious what problem it has been written to solve.

Why would anyone want to do the reverse? What is the point
in taking a Fortran solution to a problem and cloning it in
ML code? Why not just write a line of ML to solve the
problem? The ultimate irony is that it's very likely that
ML will use a highly optimised Fortran library itself,
possibly the exact same code.

"Steve Amphlett" <Firstname.Lastname@Where-I-Work.com> >
> I was expecting to be flamed by the OP and others for my
> off-hand profanity and lack of tangible help. But I
> wasn't, so I'll dig my hole a bit deeper.
>
> We have a lot of requests here for converting terse and
> instantly understandable ML code into C, C++ or Fortran.
> They are understandable - many algorithms are prototyped
in
> ML, in my view the best enviroment available for this
sort
> of thing. C or Fortran code to do what ML can do in one
> line is always going to be a lot bigger, loopy and not
> instantly obvious what problem it has been written to
solve.
>
> Why would anyone want to do the reverse? What is the
point
> in taking a Fortran solution to a problem and cloning it
in
> ML code? Why not just write a line of ML to solve the
> problem? The ultimate irony is that it's very likely
that
> ML will use a highly optimised Fortran library itself,
> possibly the exact same code.
>


Ok, so guessing your problem from the example vectors you
gave...

input: [0 1 2 2 2 2 2 3 3 3 3 3 3 4 4 4 10 10 10...]
output: [0 1 2 1 1 1 1 3 1 1 1 1 1 4 1 1 10 1 1...]

Something fairly trivial in Matlab like this will do this:

%%%%%%%%%%%%%%%%%%%%%%%%%%
x=[0 1 2 2 2 2 2 3 3 3 3 3 3 4 4 4 10 10 10];
y=ones(size(x));
idx=[1 1+find(diff(x))];
y(idx)=x(idx)

y =

  Columns 1 through 18

     0 1 2 1 1 1 1 3 1
1 1 1 1 4 1 1 10 1

  Column 19

     1
%%%%%%%%%%%%%%%%%%%%%%%%%%


Possibly not what you want, but it does the job. There are
many other ways to do this in Matlab, ALL of them clearer
than that chunk of Fortran.

On 27 Jun, 10:28, "Steve Amphlett" <Firstname.Lastn...@Where-I-
Work.com> wrote:

> We have a lot of requests here for converting terse and
> instantly understandable ML code into C, C++ or Fortran. =A0
> They are understandable - many algorithms are prototyped in
> ML, in my view the best enviroment available for this sort
> of thing. =A0C or Fortran code to do what ML can do in one
> line is always going to be a lot bigger, loopy and not
> instantly obvious what problem it has been written to solve.

Not necessarily. If the C or Fortran programs are well
structured, one can write code that looks virtually
indistinguishable from Matlab.

The big difference lies in the craftmanship of the programmer.
Poor programmers write poor code, no matter what language
they work in.

> Why would anyone want to do the reverse? =A0What is the point
> in taking a Fortran solution to a problem and cloning it in
> ML code?

The obvious reason is maintainability and portability.
I can do what I want as long as I have matlab and C++
available. I don't have any particular desire to start
messing with one of the gazillions of fortran standards
that are around; whatever fortran code one happens to
come across is certain *not* to conform to any of them.

Of course, once one does the reverese engineering one
should make the main effort to get an algorithm pseudocode,
so that one understands its purpose, and then implement
it later in whatever language one likes.

>=A0Why not just write a line of ML to solve the
> problem?

That would just repeat the problem. At some point one hits
the ceiling of what matlab is useful for (and that point
happens a lot sooner than most matlab users like), and one
has to port from matlab to something else.

If a program or routine is worth the while, then it is
inevitable that some time down the line somebody want
a C, C++, or Java or whatever version, and one needs to
convert from matlab.

That's just how things go.

Far better then, to have a pseudocode type of description
of the algorithm and implement it from scratch in the
target language.

>=A0The ultimate irony is that it's very likely that
> ML will use a highly optimised Fortran library itself,
> possibly the exact same code.

Rune

"John D'Errico" <woodchips@rochester.rr.com> wrote in
message <g41p4t$ptf$1@fred.mathworks.com>...
>
> Even new fortran
> code often has the same flaws, even though
> there are now better constructs to be found
> in the new fortran versions.

You got that right. I doubt they even teach Fortran at
universities anymore. New Fortran code is almost always
written by "old" Fortran programmers who haven't taken the
trouble to learn the new features and will continue to
write F77 style stuff. Suppose I gathered a random sample
of Fortran programmers from my work and asked them to
write code to assign one multi-dimensional matrix to
another one. I bet 9 out of 10, maybe even all 10, would
write multiple nested loops to do this, not even realizing
that a simple A = B assignment works just fine in the
Fortran compiler they already have.

James Tursa

"Steve Amphlett" <Firstname.Lastname@Where-I-Work.com>
wrote in message <g428ai$6ct$1@fred.mathworks.com>...
>
> Why would anyone want to do the reverse? What is the
point
> in taking a Fortran solution to a problem and cloning it
in
> ML code? Why not just write a line of ML to solve the
> problem?

The obvious answer, of course, is that somebody else has
already solved your problem but they happened to code it
in Fortran (or C or whatever). Rather than starting from
scratch, it may be much quicker to simply translate the
code line-by-line to MATLAB.

Another reason would be to have an independent result to
compare with. Even if one were to solve the problem and
write MATLAB code from scratch, it might be nice to do a
direct translation of working & tested Fortran code (to
minimize potential of coding translation error) to see if
it gives the same answer as the MATLAB code. "mex"ing the
Fortran code is another option, of course, in getting
comparison results.

James Tursa

"James Tursa" <aclassyguywithaknotac@hotmail.com> wrote in message
<g43cp9$cub$1@fred.mathworks.com>...
> "John D'Errico" <woodchips@rochester.rr.com> wrote in
> message <g41p4t$ptf$1@fred.mathworks.com>...
> >
> > Even new fortran
> > code often has the same flaws, even though
> > there are now better constructs to be found
> > in the new fortran versions.
>
> You got that right. I doubt they even teach Fortran at
> universities anymore. New Fortran code is almost always
> written by "old" Fortran programmers who haven't taken the
> trouble to learn the new features and will continue to
> write F77 style stuff. Suppose I gathered a random sample
> of Fortran programmers from my work and asked them to
> write code to assign one multi-dimensional matrix to
> another one. I bet 9 out of 10, maybe even all 10, would
> write multiple nested loops to do this, not even realizing
> that a simple A = B assignment works just fine in the
> Fortran compiler they already have.
>
> James Tursa

EXACTLY. And since anybody new who learns
to use fortran is most likely to learn it from one
of those old hackers or by reading/modifying
old code, they too will learn to write in that
style. Memes persist, even when they are not
beneficial. At the very least, it may take
generations to see them die away.

John

"James Tursa" <aclassyguywithaknotac@hotmail.com> wrote in
message <g43cp9$cub$1@fred.mathworks.com>...
> "John D'Errico" <woodchips@rochester.rr.com> wrote in
> message <g41p4t$ptf$1@fred.mathworks.com>...
>
> You got that right. I doubt they even teach Fortran at
> universities anymore. New Fortran code is almost always
> written by "old" Fortran programmers who haven't taken
the
> trouble to learn the new features and will continue to
> write F77 style stuff. Suppose I gathered a random sample
> of Fortran programmers from my work and asked them to
> write code to assign one multi-dimensional matrix to
> another one. I bet 9 out of 10, maybe even all 10, would
> write multiple nested loops to do this, not even
realizing
> that a simple A = B assignment works just fine in the
> Fortran compiler they already have.

A bit [OT] I know, but hey, since I'm drawing heavy fire
already, here's some more views to flame me about.

I see Fortran as a language that's continually changing to
try to keep up with more modern languages. The die-hards
always claim that Fortran is fast because its simplicity
makes it easier for compilers to optimise (undoutedly true
for Fortran 66 constructs). And then in the next breath
they point out all the new features added to the latest
(77, 90, 95, ...) version that have added all the
flexibility of newer languages and are clearly are no
easier to optimise than any other language. The newer
incantations of Fortran just allow old code to persist (and
fester, undocumented and unmaintainable).

On 28 Jun, 11:22, "Steve Amphlett" <Firstname.Lastn...@Where-I-
Work.com> wrote:

> I see Fortran as a language that's continually changing to
> try to keep up with more modern languages.

There is one sole reason for teaching (and learning) Fortran
these days: To be able to read and understand old code, in
order to port the algoprithms to some other language.
The fortran language as such is obsolete.

>=A0The die-hards
> always claim that Fortran is fast because its simplicity
> makes it easier for compilers to optimise (undoutedly true
> for Fortran 66 constructs).

Not quite true. The reason Fortran is fast is that it
lacks dynamic memory management (that was added in
fortran 90 or 95, a mere 15 years ago). Everything is
easy once the memory maps are fixed at compile time.

>=A0And then in the next breath
> they point out all the new features added to the latest
> (77, 90, 95, ...) version that have added all the
> flexibility of newer languages and are clearly are no
> easier to optimise than any other language.

Sure. Selective memory must be most convenient.
I wish I had that, too...

As for optimizations, I've played a bit with
template metaprogramming in C++ for some time now,
and it seems to be one serious beast. Templates
allow the programmer to code readable code, at the
same time it allows the compiler to do some
serious optimization.

>=A0The newer
> incantations of Fortran just allow old code to persist (and
> fester, undocumented and unmaintainable).

Most certainly agreed!

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote in message ...
> Not quite true. The reason Fortran is fast is that it
> lacks dynamic memory management (that was added in
> fortran 90 or 95, a mere 15 years ago). Everything is
> easy once the memory maps are fixed at compile time.
>

That's not correct ... unless you abuse C's malloc.

On 30 Jun, 14:17, "Tim Davis" <da...@cise.ufl.edu> wrote:
> Rune Allnor <all...@tele.ntnu.no> wrote in message ...
> > Not quite true. The reason Fortran is fast is that it
> > lacks dynamic memory management (that was added in
> > fortran 90 or 95, a mere 15 years ago). Everything is
> > easy once the memory maps are fixed at compile time.
>
> That's not correct ... unless you abuse C's malloc.

I don't see your point?

If you use malloc then the memory mapping is done at run-time,
right? I was pointing out that 'classical' fortran does not
provide the tools for dynamic memory allocation. So the
fortran compiler knows the memory map up front, which means
it can optimize far more aggressively than a C compiler
which needs to account for dynamic memory allocation at
run-time.

Rune

"Tim Davis" <davis@cise.ufl.edu> wrote in message
<g4aisc$a9d$1@fred.mathworks.com>...
> Rune Allnor <allnor@tele.ntnu.no> wrote in message ...
> > Not quite true. The reason Fortran is fast is that it
> > lacks dynamic memory management (that was added in
> > fortran 90 or 95, a mere 15 years ago). Everything is
> > easy once the memory maps are fixed at compile time.
> >
>
> That's not correct ... unless you abuse C's malloc.

Tim, please expand. I always learn things from your posts.

Rune Allnor <allnor@tele.ntnu.no> wrote in message
<1056b80b-2c64-4280-96af-388f717eda98@59g2000hsb.googlegroups.com>...
> On 28 Jun, 11:22, "Steve Amphlett"
<Firstname.Lastn...@Where-I-
> Work.com> wrote:
[snip]
> Not quite true. The reason Fortran is fast is that it
> lacks dynamic memory management (that was added in
> fortran 90 or 95, a mere 15 years ago). Everything is
> easy once the memory maps are fixed at compile time.

Fortran bans implicit aliasing (addressing the same memory
through multiple variables, arguments, common etc) - unless
you state that values are EQUIV they are supposed to be
separate. I understood that this permits optimisers to avoid
more memory accesses than with other languages (like C,
where aliasing is permitted) and keep more intermediate
values in registers. For the same reason, badly written
Fortran (that ignores the 'no aliasing' rule) can break when
optimised.

On 30 Jun, 18:20, "Andy Robb" <ajr...@hotmail.com> wrote:

> badly written
> Fortran (that ignores the 'no aliasing' rule) can break when
> optimised.

I am, as you understand, no particular fan of fortran.
While I had developed that view from various bad experiences
over several years, the real clincher was an anecdote a
colleague of mine once told: He had been able to make
a variable named 1 (digit one) which contained the
numerical value 2.

As he said, 'I only tried it to test if it worked, but
it was an interesting experience to try and make sense of
the code.'

I have no idea how he did it or if he used some
particularly arcane variant of fortran, though.

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote in message
<b4aac854-e632-4853-a549-
43f923cd5caa@k13g2000hse.googlegroups.com>...
> On 30 Jun, 18:20, "Andy Robb" <ajr...@hotmail.com> wrote:
>
> > badly written
> > Fortran (that ignores the 'no aliasing' rule) can break
when
> > optimised.
>
> I am, as you understand, no particular fan of fortran.
> While I had developed that view from various bad
experiences
> over several years, the real clincher was an anecdote a
> colleague of mine once told: He had been able to make
> a variable named 1 (digit one) which contained the
> numerical value 2.
>
> As he said, 'I only tried it to test if it worked, but
> it was an interesting experience to try and make sense of
> the code.'
>
> I have no idea how he did it or if he used some
> particularly arcane variant of fortran, though.

We have been bitten by that more than once (or is that more
than twice?). When passing a literal value "1" to a
function or subroutine it gets passed by reference.
Modifying that reference may have side effects depending on
the compiler. I don't recall off the top of my head which
platform was most recently a problem, it may have been f90
on an AlphaServer.

My beef is the whole line length issue. Lines over 72
chars get trimmed without warning. This, combined with
weak typing has wasted many hours of my time. Hmm, lets
crop this line at column 72, creating a reference to an
undeclared variable (which is now implicitly declared as
float and set to zero).

Rune Allnor wrote:
...

> I have no idea how he did it or if he used some
> particularly arcane variant of fortran, though.


While that is a common-told tale, it is _NOT_ a "feature" of any version
of Fortran that anybody today is likely to be able to even find; that
type of implementation having almost completely disappeared 30 years ago
or so.

Spreading such fud, not to mention simply outright incorrect
information, particularly in a non-Fortran ng is simply trolling or
spreading flame bait and should be curtailed.

If you were, otoh, to want to engage in a polite discussion of the
features both pro and con of Fortran vis a vis any other language, there
are plenty in comp.lang.fortran who will oblige in whatever level of
technical depth you wish to engage.

--

Steve Amphlett wrote:
> Rune Allnor <allnor@tele.ntnu.no> wrote in message
> <b4aac854-e632-4853-a549-
> 43f923cd5caa@k13g2000hse.googlegroups.com>...
>> On 30 Jun, 18:20, "Andy Robb" <ajr...@hotmail.com> wrote:
>>
>>> badly written
>>> Fortran (that ignores the 'no aliasing' rule) can break
> when
>>> optimised.
>> I am, as you understand, no particular fan of fortran.
>> While I had developed that view from various bad
> experiences
>> over several years, the real clincher was an anecdote a
>> colleague of mine once told: He had been able to make
>> a variable named 1 (digit one) which contained the
>> numerical value 2.
>>
>> As he said, 'I only tried it to test if it worked, but
>> it was an interesting experience to try and make sense of
>> the code.'
>>
>> I have no idea how he did it or if he used some
>> particularly arcane variant of fortran, though.
>
> We have been bitten by that more than once (or is that more
> than twice?). When passing a literal value "1" to a
> function or subroutine it gets passed by reference.
> Modifying that reference may have side effects depending on
> the compiler. I don't recall off the top of my head which
> platform was most recently a problem, it may have been f90
> on an AlphaServer.

I've not seen a modern compiler that would do that in some 20 years or
more...

program fud
   implicit none

   call foo(1)
   write(*,*) 1
end

subroutine foo(i)
   implicit none
   integer,intent(inout) :: i

   i = 2
   return
end subroutine

C:\MSVisualStudio\MyProjects\Temp> temp
forrtl: severe (157): Program Exception - access violation
Image PC Routine Line Source
temp.exe 0040101F FUD 5 temp.f90
...

Only ones I ever used that would actually not recognize the literal in
the argument list were, in fact, on a Philco 2000 and CDC 6600/Cyber and
DEC 10/20, etc., era machines/compilers.

> My beef is the whole line length issue. Lines over 72
> chars get trimmed without warning. ...

Only if you don't use the warnings switch that every compiler I'm aware
of currently available has...

Compiler Options
  ...
  /[no]warn:keyword Specifies the level of warning messages issued.
         Keywords are [no]alignments, ..., [no]truncated_source, ...

Not to mention, of course, that for roughly 20 years now, Fortran has
had "free form" source files and most compilers also have options that
allow one to specify source lines longer than 72 columns for fixed
source if desired.

Combined w/ the use of IMPLICIT NONE which will flag any misspelled
variables, it should be a rare instance indeed.

Thus there are a multitude of tools available to prevent the problem or
to easily diagnose the symptoms if one will simply avail themselves of
them rather than repeat mantras of yore.

--

On 30 Jun, 19:35, dpb <n...@non.net> wrote:
> Rune Allnor wrote:
>
> ...
>
> > I have no idea how he did it or if he used some
> > particularly arcane variant of fortran, though.
>
> While that is a common-told tale, it is _NOT_ a "feature" of any version
> of Fortran that anybody today is likely to be able to even find; that
> type of implementation having almost completely disappeared 30 years ago
> or so.

Doesn't matter. If you program fortran, you need to
goard against the worst-case scenario.

> Spreading such fud, not to mention simply outright incorrect
> information,

What is incorrect? That I heard the tale? The contents
of the tale?

> particularly in a non-Fortran ng is simply trolling or
> spreading flame bait and should be curtailed.

The OP in this thread wanted to know how to deal with
legacy code witten in fortran. My posts in this thread
is an attempt to show why fortran is best left alone,
as the arcaic language it arguably is.

> If you were, otoh, to want to engage in a polite discussion of the
> features both pro

There are none.

> and con of Fortran vis a vis any other language, there
> are plenty in comp.lang.fortran who will oblige in whatever level of
> technical depth you wish to engage.

As I said before, I have no interest in fortran as such.
Fortran is only relevant for historical reasons. There
is lots of legacy code around (and it will probably stay
that way for a very long time to come.) There is only one
reasonable way to deal with legacy fortran code, and that
is to find out what the code is supposed to do, and then
record the algorithm in terms of human-readable pseudo-code.

After one has the pseudo code one can implement the algorithm
in matlab, java, C, C++ or whatever other language of choise.
And in 50 or 100 years, when those languages have reached the
arcaic status fortran has today, one can reimplement the
algorithms once more in whatever language is contemporary
at the time.

Rune

Rune Allnor wrote:
...
> I have no idea how he did it or if he used some
> particularly arcane variant of fortran, though.

And so, of course, you continue to repeat ancient history as modern fact. :(

In addition to the other demonstration, if one simply uses the features
of any current Fortran compiler, the programmer error will be caught at
compilation...

module debunk
   contains

   subroutine foo(i)
     implicit none
     integer,intent(inout) :: i

     i = 2
     return
   end subroutine
end module

program fud
   use debunk
   implicit none

   call foo(1)
   write(*,*) 1
end

C:\MSVisualStudio\MyProjects\Temp> df -nolog temp.f90
temp.f90
temp.f90(17) : Error: An actual argument is an expression or constant;
this is not valid since the associated dummy argument has the explicit
INTENT(OUT) or INTENT(INOUT) attribute. [1]
     call foo(1)
-------------^


--

Rune Allnor wrote:
...

> Doesn't matter. If you program fortran, you need to
> goard against the worst-case scenario.

No, all one has to do is use any current compiler (which will still
compile legacy code).

>> Spreading such fud, not to mention simply outright incorrect
>> information,
>
> What is incorrect? That I heard the tale? The contents
> of the tale?

The applicability of the tale in today's environment.

>> particularly in a non-Fortran ng is simply trolling or
>> spreading flame bait and should be curtailed.
>
> The OP in this thread wanted to know how to deal with
> legacy code witten in fortran. My posts in this thread
> is an attempt to show why fortran is best left alone,
> as the arcaic language it arguably is.

And, they're totally off base. The best way to deal w/ legace Fortran
code is to use a modern Fortran compiler.

>> If you were, otoh, to want to engage in a polite discussion of the
>> features both pro
>
> There are none.

Simply untrue, even if you personally think so...

...

> As I said before, I have no interest in fortran as such.
...

Then I would suggest you simply ignore any thread containing the word as
you obviously are totally out of touch w/ the current state of Fortran.

You'll do far more good in letting those with actual experience and
expertise in the area helping whoever.

--

On 30 Jun, 20:43, dpb <n...@non.net> wrote:
> Rune Allnor wrote:

> >> particularly in a non-Fortran ng is simply trolling or
> >> spreading flame bait and should be curtailed.
>
> > The OP in this thread wanted to know how to deal with
> > legacy code witten in fortran. My posts in this thread
> > is an attempt to show why fortran is best left alone,
> > as the arcaic language it arguably is.
>
> And, they're totally off base. =A0The best way to deal w/ legace Fortran
> code is to use a modern Fortran compiler.

I'll tell you another anecdote. This one I watched unfold.

In 1996 I had a summer internship with one of the really
prestigious research institutions. While I was there, one
of the staff was working on some nifty numerical simulation
code. He had the best computer available at the time,
3 times as fast, MHz wise, as the competition as well as a
seriously streamlined CPU.

This guy used C or C++ (I don't remember) and he used the
modern compiler availabe at this beast of a computer.
Used every bell and whistle; squeezed every drop of
performance out of the thing.

And produced a 5-years ahead of contemporary state-of-the-
art software. As I said, I watched the guy work and I wathced
the people use his software.

A few years later, in 2000, I worked at a different research
institute. My then colleague (incidentially the same guy who
told me about the fortran 1=3D2 thing) wanted to get a copy of
this software. He got the source code and tried to compile it.

It turned out that the programmer had used the 1996 state-of-
the-art computer, a DEC Alpha running AXP. Needless to say, we
never got the simulation code to compile.

Except that 2000 incident, I never heard of or saw a DEC Alpha
after 1996.

My point is that selecting a programming language is a
gamble, at best. What is 'modern' today is obsolete
tomorrow. Once one accepts that, one sees how to handle
bad situations when they occur. There is a time to patch
worn programs. There is a time start over.

Once people younger than 55 encounter fortran, the obvious
choise is to start over with some other language. After
having documented the algorithm.

> > As I said before, I have no interest in fortran as such.
>
> ...
>
> Then I would suggest you simply ignore any thread containing the word as
> you obviously are totally out of touch w/ the current state of Fortran.
>
> You'll do far more good in letting those with actual experience and
> expertise in the area helping whoever.

My interest in fortran might be minuscule, but I do
have a strong interest inguiding innocent, unsuspecting
people away from wasting time and energy on essentially
useless efforts; they might become my colleagues some day.

Rune

Rune Allnor wrote:
...
> I'll tell you another anecdote. This one I watched unfold.
>
...
> My point is that selecting a programming language is a
> gamble, at best. What is 'modern' today is obsolete
> tomorrow. Once one accepts that, one sees how to handle
> bad situations when they occur. There is a time to patch
> worn programs. There is a time start over.
>
> Once people younger than 55 encounter fortran, the obvious
> choise is to start over with some other language. After
> having documented the algorithm.
...

It isn't nearly as "obvious" as you would like to make it, imo.

The moral or your story isn't the compiler or the language, it's the
decision to "use every possible bell and whistle" within the language
(or more generally, the OS/hardware).

The actual strength of Fortran is that F08 _will_ compile virtually all
legacy FORTRAN. That some used non-standard extensions or wrote less
than perfectly legible code is independent of the language--as your
example shows, one can do that in far more "modern" languages than F77.

I reiterate the answer isn't universally to trash operating code in
favor or rewriting and to continue to pull these hoary chestnuts out as
being indicative of anything regarding modern Fortran or the basis for a
decision of what to do w/ legacy code is pulling punches on guiding the
"young and innocent" at best.

At least make arguments based on the current state of affairs, not that
of 20, 30, even 40 years ago.

--

dpb <none@non.net> wrote in message

> module debunk
> contains
>
> subroutine foo(i)
> implicit none
> integer,intent(inout) :: i
>
> i = 2
> return
> end subroutine
> end module
>
> program fud
> use debunk
> implicit none
>
> call foo(1)
> write(*,*) 1
> end

Above is Fortran 95 standard-conforming. But I think the
code below is in violation of the standard, as an explicit
interface would be required.

> program fud
> implicit none
>
> call foo(1)
> write(*,*) 1
> end
>
> subroutine foo(i)
> implicit none
> integer,intent(inout) :: i
>
> i = 2
> return
> end subroutine

If you modify the routine to

program fud

implicit none

interface
  subroutine foo(i)
    implicit none
    integer,intent(inout) :: i
  end subroutine foo
end interface

call foo(1)
write(*,*) 1

end program fud

subroutine foo(i)
implicit none
integer,intent(inout) :: i

i = 2
end subroutine foo

I get error messages from pathf90, ifort, and gfortran. See
below:

[joachim@scorpio ~]$ pathf90 temp.f90

call foo(1)
         ^
pathf95-786 pathf90: ERROR FUD, File = temp.f90, Line = 12,
Column = 10
  An actual argument must be definable when associated with
a dummy argument that has INTENT(OUT) or INTENT(INOUT).

pathf95: PathScale(TM) Fortran Version 3.1 (f14) Mon Jun 30,
2008 15:43:21
pathf95: 22 source lines
pathf95: 1 Error(s), 0 Warning(s), 0 Other message(s), 0 ANSI(s)

********************

[joachim@scorpio ~]$ gfortran temp.f90
 In file temp.f90:12

call foo(1)
        1
Error: Actual argument at (1) must be definable to match
dummy INTENT = OUT/INOUT

*******************

[joachim@scorpio ~]$ ifort temp.f90
fortcom: Error: temp.f90, line 12: An actual argument is an
expression or constant; this is not valid since the
associated dummy argument has the explicit INTENT(OUT) or
INTENT(INOUT) attribute. [1]
call foo(1)
---------^
compilation aborted for temp.f90 (code 1)

Joachim wrote:
...
> Above is Fortran 95 standard-conforming. But I think the
> code below is in violation of the standard, as an explicit
> interface would be required.
>
>> program fud
>> implicit none
>>
>> call foo(1)
>> write(*,*) 1
>> end
>>
>> subroutine foo(i)
>> implicit none
>> integer,intent(inout) :: i
>>
>> i = 2
>> return
>> end subroutine
...

I don't think it's in violation of the Standard at all; nothing
_requires_ one to use all available features.

What is true is that for a compiler to be _certain_ to catch the
assignment error is that an interface be present; whether that is
provided manually as you did in your example or is generated via the use
of the module is immaterial for this point.

The point of my example w/o the interface was to show that modern
compilers will still catch it on execution even if the programmer didn't
make use of the features that allow it to be caught during the
compilation stage.

--

dpb <none@non.net> wrote in message
> I don't think it's in violation of the Standard at all;

Just looked it up--I take it back. (It would be required by
the standard, for example if dummy argument "i" was
assumed-shape/pointer/target/optional or if we referenced
the procedure differently.)

dpb wrote:
> Rune Allnor wrote:
> ...
>
>> I have no idea how he did it or if he used some
>> particularly arcane variant of fortran, though.
>
>
> While that is a common-told tale, it is _NOT_ a "feature" of any version
> of Fortran that anybody today is likely to be able to even find; that
> type of implementation having almost completely disappeared 30 years ago
> or so.
>

Not a modern Fortran compiler certainly, but the f2c + gcc combination
hasn't completely disappeared yet.

LOL.


C:\temp>type Source1.f

        call doubleme(1.0)
        print *,1.0
        end

        subroutine doubleme(x)
        x=x*2.0
        return
        end

C:\temp>f2c Source1.f
Source1.f:
    MAIN:
    doubleme:

C:\temp>gcc Source1.c -lfrtbegin -lg2c

C:\temp>a
   2.

user1 wrote:
...

> Not a modern Fortran compiler certainly, but the f2c + gcc combination
> hasn't completely disappeared yet.
>
...

Well, it should, then...or at least that "feature" should be fixed. :(

Have to admit I've never used that combination, though, so hadn't
thought to try it.


--

dpb wrote:
> user1 wrote:
> ...
>
>> Not a modern Fortran compiler certainly, but the f2c + gcc combination
>> hasn't completely disappeared yet.
>>
> ...
>
> Well, it should, then...or at least that "feature" should be fixed. :(
>
> Have to admit I've never used that combination, though, so hadn't
> thought to try it.
>
>
> --

On some unix / linux variants, commonly some 10 years ago, the f2c + gcc
combination was automated by a shell script named "f77" or "fort77".
This could mislead a user into thinking that he was using a real Fortran
compiler.