Fortran - Help please with a small code conversion

Author

Help please with a small code conversion

Jason

2004-10-19, 3:58 pm

I am trying to convert a piece of FORTRAN code to C++.

write(ifile,*) h(i,j)

Does this simply write to a file a entry from a Ith by Jth entry of a
matrix? If so what does (ifile, *) do? Does this make the entry
added to a file called (ifile)?

Also there is another line that has me stuck

implicit double precision(a-h,o-z)

I am not sure the significance of implicit. How could I get the same
effect using c++?

Jason Spalding

Gareth Owen

2004-10-19, 3:58 pm

jspaldin@umflint.edu (Jason) writes:

> I am trying to convert a piece of FORTRAN code to C++.
>
> write(ifile,*) h(i,j)
>
> Does this simply write to a file a entry from a Ith by Jth entry of a
> matrix?

Yes. Specifically it writes to a file that had previously been opened and
associated with the unit number 'ifile' (which is an integer). The opening
function will look something like:

open (unit=ifile,file='filename.dat', [other stuff here])

The '*' just tells it to write it out in whatever default format is associated
with the type of h(i,j).

> implicit double precision(a-h,o-z)
> I am not sure the significance of implicit.

It says any variable whose name begins with the the letter a-h or o-z are to
be treated as if explicitly declared as double precision real numbers.

> How could I get the same effect using c++?

You don't. You've got to declare your variables explicitly in C++.
--
Gareth Owen
Early to rise, and early to bed / Makes a man healthy but socially dead

Dave Seaman

2004-10-19, 3:58 pm

On 19 Oct 2004 10:36:02 -0700, Jason wrote:
> I am trying to convert a piece of FORTRAN code to C++.

> write(ifile,*) h(i,j)

> Does this simply write to a file a entry from a Ith by Jth entry of a
> matrix?

Probably, but there's an outside chance that it could mean to call a
function named 'h' with arguments i and j. In Fortran you can't tell the
difference except by looking to see how (or whether) h is declared. If h
is not declared at all in that program unit, then it's a function.

>If so what does (ifile, *) do? Does this make the entry
> added to a file called (ifile)?

Not quite; ifile is an integer variable whose value is the unit number
associated with the file (sort of like file descriptors in C). The "*"
means that instead of specifying a format for the write, the program is
using "list directed output", which is somewhat similar in spirit to
using the "<<" output operator in C++, since the format is dictated by
the type of the item being written.

> Also there is another line that has me stuck

> implicit double precision(a-h,o-z)

The default specification in Fortran is

implicit real (a-h,o-z)
implicit integer (i-n)

which means you are allowed to have undeclared variables in Fortran, and
their types are inferred from the first letter of the name (hence the
saying: "God is REAL, unless declared INTEGER."). The purpose of the
implicit statement is to change the default type mapping.

> I am not sure the significance of implicit. How could I get the same
> effect using c++?

You can't. All variables must be given explicit types in C++. Think of
it as insurance againt typos.

--
Dave Seaman
Judge Yohn's mistakes revealed in Mumia Abu-Jamal ruling.
<http://www.commoncouragepress.com/i...book&bookid=228>

meek@skyway.usask.ca

2004-10-19, 8:56 pm

In a previous article, jspaldin@umflint.edu (Jason) wrote:
>I am trying to convert a piece of FORTRAN code to C++.
>
>write(ifile,*) h(i,j)
>
>Does this simply write to a file a entry from a Ith by Jth entry of a
>matrix? If so what does (ifile, *) do? Does this make the entry
>added to a file called (ifile)?
>
>Also there is another line that has me stuck
>
>implicit double precision(a-h,o-z)
>
>I am not sure the significance of implicit. How could I get the same
>effect using c++?
>
>
>Jason Spalding
implicit ... means that all variable names starting with
these letters (a,b,c,...,h and o,p,q,...,z) are typed
as double precision (8byte) floating
This includes function names.
Since (in F77 and earlier) integer vs real was determined
this way (i.e. i-n=integer, a-h,o-z=real) unless typed
explicitly, then provided this naming scheme was followed
in the program, it was easy to change to DP to choose
speed vs. accuracy. These days
co-processer is probably doing DP no matter what you choose
Chris

Kevin G. Rhoads

2004-10-20, 3:56 am

>write(ifile,*) h(i,j)

Writes out one value of the 2D matrix h,
being the value indexed at I in the first
index and at j in the second.

something like (my C is rusty)
fprintf(<appropriate format>,h[j][i]);

Richard Maine

2004-10-20, 3:56 am

@skyway.usask.ca writes:

> it was easy to change to DP to choose speed vs. accuracy. These days
> co-processer is probably doing DP no matter what you choose

I'm not entirely sure what you mean by that... but I doubt it is
true. What you may mean is that the speed of single and double
precision is often about the same...except for memory bandwidth
issues.

By the way, in my experience I have rarely seen implicit used as
an easy way to change speed vs accuracy tradeoffs. I suppose it
could happen, but that's not the uses I see. Almost all the uses
I've seen have been for one of the reasons

1. The code needs double and the programmer doesn't like doing
explicit declarations.

2. The code was originally written for a machine where single
precision was 60 or 64 bits and has since been ported to a
machine where single is 32 bits (and isn't adequate).

In neither case is speed a relevant issue; no tradeoffs involved.

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

James Van Buskirk

2004-10-20, 3:56 am

"Richard Maine" <nospam@see.signature> wrote in message
news:87u0sqw76l.fsf@vega.site...
> m

@skyway.usask.ca writes:

> Almost all the uses
> I've seen have been for one of the reasons

I have a third reason, which is rather compelling for my purposes.
As you know, I prefer IMPLICIT NONE, but in automatically
generated code I use

implicit real(wp) x

so that all variables with names starting with 'x' will get
the kind type parameter wp inherited from the module in which
the subroutine is INCLUDed. The reason for this is that I
don't know until the code has been generated what variable
names will be used, only that there will be several thousand.
To declare all these variables I would have to write both the
declarations and the code to separate files then combine them
in a separate final step. The resulting code would have
hundreds to thousands of lines of declarations that would be
meaningless and unreadable. I guard against unintentional
creation of variable names not starting with 'x' because the
host module has IMPLICIT NONE in force. I think many
programmers would use an IMPLICIT statement to make the code
generator simpler in this context. The code generator is at
http://home.comcast.net/~kmbtib/conv2b.f90 if you want to see
the kind of problem that leads me to use implicit typing.

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

glen herrmannsfeldt

2004-10-20, 3:56 am

Richard Maine wrote:

> m

@skyway.usask.ca writes:

[color=darkred]
> I'm not entirely sure what you mean by that... but I doubt it is
> true. What you may mean is that the speed of single and double
> precision is often about the same...except for memory bandwidth
> issues.

The speed is the same because, at least for x87, the calculation
is usually done to full precision, independent of the actual size.
The result is truncated when stored.

In the olden days there were two reasons to use single precision,
speed and memory. (When computers were slower and memory
was expensive.)

There are control register bits to change the fraction bits
computed by x87 processors, but I don't know any systems that
change them to match the operation being done.

-- glen

beliavsky@aol.com

2004-10-20, 3:56 am

Kevin G. Rhoads

2004-10-20, 4:06 pm

>There are control register bits to change the fraction bits
>computed by x87 processors, but I don't know any systems that
>change them to match the operation being done.

The run-time libraries usually set them to some default value.
More recently (last decade or so) WinXX systems tend to set
them also, as do just about all apps built with VC++ (the
RTL again).

But you are right, it is pretty much set and forget, not a
dynamic setting of the control for the operation at hand, not
unless you want to do it yourself.

meek@skyway.usask.ca

2004-10-20, 4:06 pm

In a previous article, Richard Maine <nospam@see.signature> wrote:
>m

@skyway.usask.ca writes:
>
>
>I'm not entirely sure what you mean by that... but I doubt it is
>true. What you may mean is that the speed of single and double
>precision is often about the same...except for memory bandwidth
>issues.

I haven't experienced it myself - I heard it from
someone who knows (and cares) more about such things than
I. I don't suggest that all compilers do that ... just
that you shouldn't expect them to use SP when you say SP.
(this was probably not Fortran ... maybe FORTRAN is more
"careful")

>
>By the way, in my experience I have rarely seen implicit used as
>an easy way to change speed vs accuracy tradeoffs. I suppose it
>could happen, but that's not the uses I see. Almost all the uses
>I've seen have been for one of the reasons
>
>1. The code needs double and the programmer doesn't like doing
> explicit declarations.
>
>2. The code was originally written for a machine where single
> precision was 60 or 64 bits and has since been ported to a
> machine where single is 32 bits (and isn't adequate).
>
>In neither case is speed a relevant issue; no tradeoffs involved.
>

These days speed may not be important ... but back when you
were paying for each cpu second it was a consideration
for those of us with shallow pockets.
Chris

>--
>Richard Maine
>email: my last name at domain
>domain: summertriangle dot net

Richard E Maine

2004-10-20, 4:06 pm

@skyway.usask.ca writes:

> I don't suggest that all compilers do that ... just
> that you shouldn't expect them to use SP when you say SP.

The only thing very similar to that is that intermediate results
might sometimes be computed with more precision than you
expect, although the variables will always be of the declared size.
That might be what was referred to. If so, one needs a little more
precision (in English :-)) to make the caution very useful. Otherwise,
people will be prompted to worry about completely unrelated things.

> These days speed may not be important ... but back when you
> were paying for each cpu second it was a consideration
> for those of us with shallow pockets.

I didn't say...well, ok, I see that it could be read that way....
anyway I didn't mean to say that speed wasn't important. I've seen
plenty of people extremely concerned about speed (including some so
concerned that they slowed things down because of mistaken impressions
of how to make things faster). I have not, however, seen people use
implicit to make speed tradeoffs - that's the point I was making. I
see lots of people concerned about speed and I see lots of uses of
implicit, but I don't think I've ever before seen the 2 things
linked. I suppose there might have been some cases somewhere, but I
feel confident in saying that it isn't the typical reason for using
implicit (which seemed implied by the post I originally responded to).

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

John Harper

2004-10-20, 8:57 pm

In article <cl3p7o$g6t$1@mozo.cc.purdue.edu>,
Dave Seaman <dseaman@no.such.host> wrote:
>On 19 Oct 2004 10:36:02 -0700, Jason wrote:
>
>
>
>Not quite; ifile is an integer variable whose value is the unit number
>associated with the file (sort of like file descriptors in C).

That's the most likely possibility. But if ifile was declared by
something like
character ifile*14
(so its value is a string of 14 characters), and if the program was f77
extended to allow * format in this context, or was a more modern version
like f95, then that write statement converts h(i,j) to a string of
characters (e.g. '-0.6666666E+66') and puts that in the variable ifile.
If that's Jason's case I leave him to sort out what happens if ifile is
longer or shorter than the character string produced by *

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

Stuart Gerchick

2004-10-21, 8:56 pm

jspaldin@umflint.edu (Jason) wrote in message news:<975427f0.0410190936.4c1f7f38@posting.google.com>...
> I am trying to convert a piece of FORTRAN code to C++.
>
> write(ifile,*) h(i,j)
>
> Does this simply write to a file a entry from a Ith by Jth entry of a
> matrix? If so what does (ifile, *) do? Does this make the entry
> added to a file called (ifile)?
>
> Also there is another line that has me stuck
>
> implicit double precision(a-h,o-z)
>
> I am not sure the significance of implicit. How could I get the same
> effect using c++?
>
>
> Jason Spalding

Jason, there are a number of possibilities for the first one. Let us
make sure we
cover all the bases

1) h(i,j) can be an element of a 2-d array
2) h(i,j) can be a function called h that takes 2 elements i,j.

There is no way to tell this without seeing the code. However, with
the code it is easy to see.
If h is declared as a variable, then it is 1. If it is not declared
it is then a function.

1) ifile can be the logical unit for a file name that is an integer
and used in an open
2) ifile can be a character string (character*20 for example), it is
an internal file. the value of
h(either element or function return) is put into the character.

write(ifile,*) h(i,j) - the ,* after the ifile is for formatting. no
formatting info is supplied. The formatting info is like in printf
where you have %s or %d.

Sponsored Links