some fortran 77 language question 
Author Message
 some fortran 77 language question

hi,
i'm very new to fortran 77 and i hope someone
can help me out.

1.code :
real*8 pa(1), sa(1), ra(1), ea(1), ta(1), aa(1), ha(1)
 integer npts, mflag

can anyone explain me the term "pa(1)" in c++ language ?
what does "(1)" stand for ? array ?

2.code :
rhos = (ps / s5) ** (1.0d0 / gama)

what does "**" stand for (in c++) ??

THANKS in Advance (really!)



Tue, 05 Feb 2008 21:45:11 GMT  
 some fortran 77 language question
Quote:

> hi,
> i'm very new to FORTRAN 77 and i hope someone
> can help me out.

> 1.code :
> real*8 pa(1), sa(1), ra(1), ea(1), ta(1), aa(1), ha(1)
>  integer npts, mflag

> can anyone explain me the term "pa(1)" in c++ language ?
> what does "(1)" stand for ? array ?

> 2.code :
> rhos = (ps / s5) ** (1.0d0 / gama)

> what does "**" stand for (in c++) ??

1. Assuming that pa,sa,.. are function arguments, this syntax is an
obsolete (by the time of f77) non-standard indication that those
arguments are arrays.  real*8 is not f77 either, but is a common
extension. In f77, this would be
double precision pa(*),...
indicating that the arrays have unspecified length. In the most common
implementations, these arguments would be the same as (C)
double *pa,...
2.  In C, that would be
rhos = pow(ps/s5 , 1./gama)


Tue, 05 Feb 2008 21:56:35 GMT  
 some fortran 77 language question

Quote:


>> hi,
>> i'm very new to FORTRAN 77 and i hope someone
>> can help me out.

>> 1.code :
>> real*8 pa(1), sa(1), ra(1), ea(1), ta(1), aa(1), ha(1)
>>  integer npts, mflag

>> can anyone explain me the term "pa(1)" in c++ language ?
>> what does "(1)" stand for ? array ?

>> 2.code :
>> rhos = (ps / s5) ** (1.0d0 / gama)

>> what does "**" stand for (in c++) ??

> 1. Assuming that pa,sa,.. are function arguments, this syntax is an
> obsolete (by the time of f77) non-standard indication that those
> arguments are arrays.  real*8 is not f77 either, but is a common
> extension. In f77, this would be
> double precision pa(*),...

If pa, sa are NOT function or subroutine arguments, however, the syntax
pa(1) is NOT obsolete; it indicates a one-dimensional array with size 1.

cheers,

Rich



Tue, 05 Feb 2008 22:00:17 GMT  
 some fortran 77 language question

Quote:

> hi,
> i'm very new to FORTRAN 77 and i hope someone
> can help me out.

> 1.code :
> real*8 pa(1), sa(1), ra(1), ea(1), ta(1), aa(1), ha(1)
>  integer npts, mflag

> can anyone explain me the term "pa(1)" in c++ language ?
> what does "(1)" stand for ? array ?

This is a bit tricky :).

In standard Fortran 77 it stands for a one-element array, and note that
in Fortran, arrays indices by default start with 1, not 0 as in C/C++.

However, if the declarations you show appear at the beginning of a
Fortran function or subroutine, they probably refer to arrays of
arbitrary size and would be written in standard Fortran 77 as

real*8 pa(*)

(ignoring the issue of real*8 vs. double precision).

Quote:

> 2.code :
> rhos = (ps / s5) ** (1.0d0 / gama)

> what does "**" stand for (in c++) ??

This is straightforward and is covered by any Fortran book or tutorial.
There are some at
http://www.dmoz.org/Computers/Programming/Languages/Fortran/Tutorials...
. To answer your question, ** means exponentiation, similar to the
pow() function in C/C++.


Tue, 05 Feb 2008 22:01:09 GMT  
 some fortran 77 language question


Quote:
> If pa, sa are NOT function or subroutine arguments, however, the syntax
> pa(1) is NOT obsolete; it indicates a one-dimensional array with size 1.

Just to be pedantic (I'm 100% sure that you understand this, Rich),
there is not actually anything obsolete or nonstandard about the pa(1)
syntax even when pa is a dummy argument.... It's just that if pa is a
dummy argument, the odds are high that the code is intending the
nonstandard meaning.

I have, however, seen cases of dummy arguments declared with dimensions
of 1 and meaning it literally and validly. That is, admittedly, rare.
Odds are quite high that the nonstandard meaning is intended.

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



Tue, 05 Feb 2008 23:14:19 GMT  
 some fortran 77 language question

Quote:



>>If pa, sa are NOT function or subroutine arguments, however, the syntax
>>pa(1) is NOT obsolete; it indicates a one-dimensional array with size 1.

> Just to be pedantic (I'm 100% sure that you understand this, Rich),
> there is not actually anything obsolete or nonstandard about the pa(1)
> syntax even when pa is a dummy argument.... It's just that if pa is a
> dummy argument, the odds are high that the code is intending the
> nonstandard meaning.

Agreed.

Quote:

> I have, however, seen cases of dummy arguments declared with dimensions
> of 1 and meaning it literally and validly. That is, admittedly, rare.
> Odds are quite high that the nonstandard meaning is intended.

Out of interest, which variant of Fortran does the pa(1) dummy argument
idiom stem from?

cheers,

Rich



Tue, 05 Feb 2008 23:26:50 GMT  
 some fortran 77 language question


Quote:
> Out of interest, which variant of Fortran does the pa(1) dummy argument
> idiom stem from?

F66, where there was no standard-conforming way to achieve the same
effect. F66 in turn, inherited the idiom from earlier versions, but it
is tricker to discuss "standard conformance" in earlier versions.

The (*) notation was introduced in f77 and gave a standard-conforming
way to do what people had been "hacking" with (1) for, well, presumably
over 2 decades by then, though I can't speak first-hand on Fortran
before about 1968. I did work with several codes that originated as
Fortran IV (and even Fortran II), and they heavily used the (1) idiom.

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



Tue, 05 Feb 2008 23:37:01 GMT  
 some fortran 77 language question
On Fri, 19 Aug 2005 08:37:01 -0700, Richard E Maine

[snip]

Quote:
>The (*) notation was introduced in f77 and gave a standard-conforming
>way to do what people had been "hacking" with (1) for, well, presumably
>over 2 decades by then, though I can't speak first-hand on Fortran
>before about 1968. I did work with several codes that originated as
>Fortran IV (and even Fortran II), and they heavily used the (1) idiom.

I presume you meant it was standardized, rather than introduced, in
f77.

I remember seeing it in a version of Fortran IV in the mid 70s.  I had
been using the (1) technique (I wouldn't call it a trick - it was a
technique) since starting with Fortran IV in 1964.

The compiler that used (*) would not accept the traditional use of
(1).  But it would do (*,*,*), which was a major advance.

My recollection is that the system with (*) was an IBM of some kind,
running on Tymshare.  Maybe someone remembers that compiler.

Ken Plotkin



Wed, 06 Feb 2008 09:36:27 GMT  
 some fortran 77 language question


Quote:
> On Fri, 19 Aug 2005 08:37:01 -0700, Richard E Maine

> >The (*) notation was introduced in f77..
> I presume you meant it was standardized, rather than introduced, in
> f77.

No. I meant introduced. I had never seen it before f77. That doesn't
mean there weren't cases of it - just that I hadn't seen them. So
perhaps my saying that it was introduced then was incorrect (it
happens), but that's what I meant.

Of course, I was a bit of a novice when f77 compilers came out. There
were plenty of things I hadn't seen.

Quote:
> I had
> been using the (1) technique (I wouldn't call it a trick - it was a
> technique) since starting with Fortran IV in 1964.

I considered it a hack based on knowing the address computation formula
and realizing that it would happen to get the "right" answer (trivial in
the 1-D case, but requiring understanding of array element order in
rank>1).


Wed, 06 Feb 2008 14:33:00 GMT  
 some fortran 77 language question

Quote:

> hi,
> i'm very new to FORTRAN 77 and i hope someone
> can help me out.
> 1.code :
> real*8 pa(1), sa(1), ra(1), ea(1), ta(1), aa(1), ha(1)
>  integer npts, mflag
> can anyone explain me the term "pa(1)" in c++ language ?
> what does "(1)" stand for ? array ?

In older Fortran systems, though not necessarily standard,
it matches the [] in C (and I believe C++).

A function argument could be declared

double pa[];

or even

double pa[][10];

where the leftmost dimension is not needed for array element
calculations.  In Fortran it is the rightmost dimension,
where 1 works in systems that don't do bounds checking.

The standard allows bounds checking, and so doesn't allow
this, but it was commonly done.

-- glen



Fri, 08 Feb 2008 16:37:14 GMT  
 some fortran 77 language question
On Fri, 19 Aug 2005 23:33:00 -0700, Richard Maine

Quote:

>Of course, I was a bit of a novice when f77 compilers came out. There
>were plenty of things I hadn't seen.

Despite that, for one who has not yet lived a single lifetime you know
much.

Quote:
>I considered it a hack based on knowing the address computation formula
>and realizing that it would happen to get the "right" answer (trivial in
>the 1-D case, but requiring understanding of array element order in
>rank>1).

When I was taught Fortran back then, emphasis was placed on array
order being well-defined and always the same.

My first real programming project involved integration of a set of
ODEs.  Lots of stuff came in and out of the subroutine as m by n
arrays: m equations, n points.  Writing a routine for arbitrary n was
easy - just (m,1).  For arbitrary m, I did a version with arrays
dimensioned (1) and computed the position.

Those were the days when it was OK to know what was physically
happening in the machine.  A high level language like Fortran saved
you the tedium of writing assembly and explicitly assigning storage
locations, but you could still be aware of what the compiler did to
it.  In fact, we were taught that it was good to know something about
the innards.  That's why I considered (1) to be a technique, not a
hack.

Today, if it were allowed, it would be a hack since you're not
supposed to know what happens under the hood.

Ken Plotkin



Fri, 08 Feb 2008 22:48:03 GMT  
 some fortran 77 language question

Quote:

...
> When I was taught Fortran back then, emphasis was placed on array
> order being well-defined and always the same.
...
> Those were the days when it was OK to know what was physically
> happening in the machine.  A high level language like Fortran saved
> you the tedium of writing assembly and explicitly assigning storage
> locations, but you could still be aware of what the compiler did to
> it.  In fact, we were taught that it was good to know something about
> the innards.  That's why I considered (1) to be a technique, not a
> hack.

> Today, if it were allowed, it would be a hack since you're not
> supposed to know what happens under the hood.

That exactly parallels the instruction I received...it was, in fact, a
major loss of credit if one did not demonstrate one knew precisely this
facet of array manipulation and how to make use of it.


Fri, 08 Feb 2008 23:01:15 GMT  
 some fortran 77 language question


Quote:

> ...
> > When I was taught Fortran back then, emphasis was placed on array
> > order being well-defined and always the same...
> ...
> That exactly parallels the instruction I received...it was, in fact, a
> major loss of credit if one did not demonstrate one knew precisely this
> facet of array manipulation and how to make use of it.

Oh. You received instruction? :-)

I'm trying to recall. I think I might have taken a Fortran course in
order to get an account to be allowed to use some of the school
computers. But that course was enough of a token that I'm having trouble
recalling the course - not sure whether I actually went to any of the
lectures (I did a lot of that in undergrad school), which would explain
why they didn't stick very well in my mind. :-) I had learned Fortran
well before the course.

Where I actually learned Fortran was on the job. And yes, it certainly
involved low-level fiddly bits - including array order and also things
much less portable.

"We" had several strange array storage conventions. I recall that f77
allowed us to do a "nifty" one where we added a zero'th column to
arrays. The dimension information was all stored in that zero'th column
so that we could have subroutine calls like

  CALL ADD(X,Y,Z)

where the dimension information was passed without extra arguments.

It seemed like a good idea at the time.

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



Sat, 09 Feb 2008 00:11:57 GMT  
 some fortran 77 language question
Quote:




> > ...
> > > When I was taught Fortran back then, emphasis was placed on array
> > > order being well-defined and always the same...
> > ...
> > That exactly parallels the instruction I received...it was, in fact, a
> > major loss of credit if one did not demonstrate one knew precisely this
> > facet of array manipulation and how to make use of it.

> Oh. You received instruction? :-)

> I'm trying to recall. I think I might have taken a Fortran course in
> order to get an account to be allowed to use some of the school
> computers. But that course was enough of a token that I'm having trouble
> recalling the course - not sure whether I actually went to any of the
> lectures (I did a lot of that in undergrad school), which would explain
> why they didn't stick very well in my mind. :-) I had learned Fortran
> well before the course.

...

The Department I was in (NE, altho that's incidental) taught about a
half-semester of basic FORTRAN (this was early '60s era) in conjunction
w/ some intro numerical analysis and other semi-related stuff.  (The
course was entitled "Introduction to Nuclear Engineering" and it was a
catchall to prime NE majors ahead of what we would get if relied only on
the normal engineering math/physics sequence. It wouldnt' have qualified
as a "Computer Sci" course, but it did the basics of coding semantics
and enough to get (most of) us through the labs.

I had never seen any programming language of any sort (and don't think
there were any others in the class who had either) up to that time so if
we hadn't had that intro we would have really been lost (even more than
were were, anyway). :)

Like you and most everybody else, real training came on the job although
I personally was fortunate to end up working for the department as an
undergrad for a couple of years (I arranged to to take five years
instead of four before receiving a BS for reasons related to what was
happening elsewhere) and had a good (for the time, certainly) mentor
helping me write gamma-spec processing code so I was a little ahead of
where I'd have been otherwise.



Sat, 09 Feb 2008 00:31:24 GMT  
 some fortran 77 language question

Quote:
> Today, if it were allowed, it would be a hack since you're not
> supposed to know what happens under the hood.

Hmmm, I don't think array element order and sequence association has
changed much - I believe not at all from F77 until today, and probably
even F66 was almost identical.

I think one is still supposed to know what is happening under the hood, and
there are situations where an old fag like myself has to help out because
I _do_ know what is happening under the hood when all those C- or Java-
raised pups run into a wall. But you are _not_ supposed to _rely_ on cer-
tain of those under-the-hood workings being the same everywhere - only to
the degree the standard mandates certain behaviour which, if you want,
you can _define_ as being "not under the hood".

        Jan



Sat, 09 Feb 2008 20:14:24 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Fortran 77 simple code question

2. Fortran 77 File I/O Write and Format Question

3. Fortran 77 question

4. question about negative indices in fortran 77

5. question about negative indices in fortran 77

6. Fortran 77 question

7. A few basic questions about FORTRAN 77 program

8. Question on FORtran 77 standard

9. File access question (Fortran 77) - please e-mail answer

10. Question about HP 9000/700 Fortran 77

11. Fortran 77 question

12. Fortran 77 syntax question

 

 
Powered by phpBB® Forum Software