Fortran - Cannot make out what is wrong!Please Help:-(

Author

Cannot make out what is wrong!Please Help:-(

vashwath@rediffmail.com

2005-05-23, 3:57 am

Hi All,
ENRTY GINITL is called by setting ARRAY(1) to 10.0, ARRAY(2) to 3.0,
TIME to 45.0 and X to 0.0.The value of X is printed after calling the
ENTRY and the printed value of X is a garbage value.I am not able to
find out what am I missing.I have just started learning FORTRAN.Waiting
eagerly for your replies.

SUBROUTINE STATE(NRSTAT,ARRAY,TIME,X)
REAL*8 ARRAY(20)
REAL*8 TIME
DATA XNDA /4H"NDA/
DATA BLANK/4H" /
A = ARRAY(1)
B = ARRAY(2)
C = ARRAY(3)
D = ARRAY(4)
A1= ARRAY(5)
B1= ARRAY(6)
C1= ARRAY(7)
D1= ARRAY(8)
A2= ARRAY(9)
B2= ARRAY(10)
C2= ARRAY(11)
D2= ARRAY(12)
A3= ARRAY(13)
B3= ARRAY(14)
C3= ARRAY(15)
D3= ARRAY(16)
A4= ARRAY(17)
B4= ARRAY(18)
C4= ARRAY(19)
D4= ARRAY(20)
GO TO 1000
32 x=A*B
RETURN
3 x=A/B
RETURN
4 x=A+B+C
RETURN
1 X=(A*B*COS(C*.0174533))/ D*A1*A2*A3*A4*B1*B2*B3*B4*C1*C2*C3*C4*D1

1*D2*D3*D4
RETURN
2 X=B/A*C/D+B1/A2*D1/(A1+C1*B2)
RETURN
1000 GO TO ( 1, 2, 3, 4,100,100,100,100,100,100,100,100,100,10
0,
1100,100,100,100,100,100,100,100,100,100
,100,100,100,100,100,100,
2100, 32,
1 100),NRSTAT
100 X = XNDA
RETURN

ENTRY GINITL(ARRAY,TIME,X)
A = ARRAY(1)
B = ARRAY(2)
C = ARRAY(3)
D = ARRAY(4)
A1= ARRAY(5)
B1= ARRAY(6)
C1= ARRAY(7)
D1= ARRAY(8)
A2= ARRAY(9)
B2= ARRAY(10)
C2= ARRAY(11)
D2= ARRAY(12)
A3= ARRAY(13)
B3= ARRAY(14)
C3= ARRAY(15)
D3= ARRAY(16)
A4= ARRAY(17)
B4= ARRAY(18)
C4= ARRAY(19)
D4= ARRAY(20)
122 x=A+B
112 x=A-B
RETURN
END

Dave Weatherall

2005-05-23, 3:57 am

On Mon, 23 May 2005 04:57:16 UTC, vashwath@rediffmail.com wrote:

> Hi All,
> ENRTY GINITL is called by setting ARRAY(1) to 10.0, ARRAY(2) to 3.0,
> TIME to 45.0 and X to 0.0.The value of X is printed after calling the
> ENTRY and the printed value of X is a garbage value.I am not able to
> find out what am I missing.I have just started learning FORTRAN.Waiting
> eagerly for your replies.
>
>
> SUBROUTINE STATE(NRSTAT,ARRAY,TIME,X)
<Snip>
> ENTRY GINITL(ARRAY,TIME,X)

I'd start by checking the number of arguments for SUBROUTINE and
ENTRY. ISTR they have to match..

--
Cheers - Dave.

glen herrmannsfeldt

2005-05-23, 8:57 am

Dave Weatherall wrote:
> On Mon, 23 May 2005 04:57:16 UTC, vashwath@rediffmail.com wrote:

(snip)

[color=darkred]
> <Snip>

[color=darkred]
> I'd start by checking the number of arguments for SUBROUTINE and
> ENTRY. ISTR they have to match..

They must match the corresponding CALL statement, but they don't have
to agree with each other.

Even more fun, for FUNCTIONs with ENTRY statement the type of the
result can be different, with the function return variables all
EQUIVALENCEd to each other.

-- glen

e p chandler

2005-05-23, 8:57 am

vashwath@rediffmail.com wrote:
> Hi All,
> ENRTY GINITL is called by setting ARRAY(1) to 10.0, ARRAY(2) to 3.0,
> TIME to 45.0 and X to 0.0.The value of X is printed after calling the
> ENTRY and the printed value of X is a garbage value.I am not able to
> find out what am I missing.I have just started learning
FORTRAN.Waiting
> eagerly for your replies.
>
>
> SUBROUTINE STATE(NRSTAT,ARRAY,TIME,X)
> REAL*8 ARRAY(20)
> REAL*8 TIME
> DATA XNDA /4H"NDA/
> DATA BLANK/4H" /
> A = ARRAY(1)
> B = ARRAY(2)
> C = ARRAY(3)
[snip]
> 100 X = XNDA
> RETURN
>
> ENTRY GINITL(ARRAY,TIME,X)
> A = ARRAY(1)
> B = ARRAY(2)
> C = ARRAY(3)
> D = ARRAY(4)
[snip]
> D4= ARRAY(20)
> 122 x=A+B
> 112 x=A-B
> RETURN
> END

What does your calling program look like? If your call to GINITL does
not use X as its third argument, but you print X, then X probably will
be garbage.

With

REAL*8 FOO(20)
REAL*8 BAR
FOO(1)=10.0
FOO(2)= 3.0
BAR=45.0
BAZ=0.0
CALL GINITL(FOO,BAR,BAZ)
WRITE(*,*) BAZ
END

SUBROUTINE STATE(NRSTAT,ARRAY,TIME,X)
and so on....

The output is

C:\g77>g77 -o fubar.exe fubar.f

C:\g77>fubar
7.

C:\g77>

vashwath@rediffmail.com

2005-05-23, 8:57 am

There is no change in the result even after changing the prototype.Am I
making any mistake in the calling program please check. Below is the
code of the calling program.
PROGRAM MAIN
REAL*8 ARR(20)
REAL*8 TIME
REAL*8 OUTPUT;
INTEGER NRSTAT=112

ARR(1)=10.0
ARR(2)=3.0
OUTPUT=0.0

CALL GINITL(NRSTAT,ARR,TIME,OUTPUT)

WRITE(*,*)OUTPUT

STOP

Ian Bush

2005-05-23, 8:57 am

vashwath@rediffmail.com wrote:

> There is no change in the result even after changing the prototype.Am I
> making any mistake in the calling program please check. Below is the
> code of the calling program.
> PROGRAM MAIN
> REAL*8 ARR(20)
> REAL*8 TIME
> REAL*8 OUTPUT;

Well one thing that is wrong is that output is declared by the non-standard
REAL*8 in the calling routine, but in the routine itself it is not declared at
all. This is almost certainly an argument mismatch, and is certainly machine
dependent. Implicit None is your friend here,

This is still horrible code,

Ian

vashwath@rediffmail.com

2005-05-23, 8:57 am

Do you mean I should declare this inside ENTRY also?I tried
this(Declared in SUBROUTINE STATE and inside entry) but it was not
compiling.It was giving the following error

" ENTRY GINITL(NRSTAT,ARRAY,TIME,X)
1
STATE.F:47: (continued):
REAL*8 ARRAy(20)
2
Statement at (2) invalid in context established by statement at (1)
Once this is solved I will improve the code."

Also please let me know what is the standard way of declaring a double
precision variable.
Thanks in Advance

John Mansell

2005-05-23, 8:57 am

>There is no change in the result even after changing the prototype.Am I
>making any mistake in the calling program please check. Below is the
>code of the calling program.
> PROGRAM MAIN
> REAL*8 ARR(20)
> REAL*8 TIME
> REAL*8 OUTPUT;
> INTEGER NRSTAT=112
>
>
> ARR(1)=10.0
> ARR(2)=3.0
> OUTPUT=0.0
>
>
> CALL GINITL(NRSTAT,ARR,TIME,OUTPUT)
Surely,
call ginitl(arr,time,output)

>
>
> WRITE(*,*)OUTPUT
>
>
> STOP
end
>
Also, x in the routine body is default real. It should be real*8.
Finally, x=a-b sets x to 7.0.

Omitting to declare x as real*8 would result in the last 4 bytes of
OUTPUT being untouched by the code in the subroutine body (I'm assuming
4-byte default real here - by no means universal, but common enough),
but the subroutine would set the bytes in x (the first 4 in OUTPUT) to a
bit pattern corresponding to a default real, which almost certainly
would be garbage when interpreted as real*8.

I recall that on DEC 10 and VAX/VMS, you could get away with this,
because double precision was simply a single precision word plus a word
containing the bits of the extra precision. No chance with IEEE, though.

If your compiler supports implicit none, I suggest that you use it.
--
John Mansell john at wcompsys dot co dot uk

John Mansell

2005-05-23, 8:57 am

You need to declare all variables just after the subroutine declaration.
In f77, DOUBLE PRECISION is the standard alternative for REAL*8. ENTRY
points may then appear among the executable statements. The ENTRY points
need not have the same parameter list as the SUBROUTINE.

SUBROUTINE STATE(NRSTAT,ARRAY,TIME,X)
DOUBLE PRECISION TIME,x
integer nrstat
DOUBLE PRECISION ARRAY(20)

Arjen Markus

2005-05-23, 3:58 pm

vashwath@rediffmail.com wrote:
>
> There is no change in the result even after changing the prototype.Am I
> making any mistake in the calling program please check. Below is the
> code of the calling program.
> PROGRAM MAIN
> REAL*8 ARR(20)
> REAL*8 TIME
> REAL*8 OUTPUT;
> INTEGER NRSTAT=112
>
> ARR(1)=10.0
> ARR(2)=3.0
> OUTPUT=0.0
>
> CALL GINITL(NRSTAT,ARR,TIME,OUTPUT)
>
> WRITE(*,*)OUTPUT
>
>
> STOP

Maybe it is time to step back and ask yourself the following:

What is it you are trying to achieve? Can you tell us
in words, not code, what that is?

The ENTRY statement is not the most basic of statements -
so if you are learning FORTRAN (I suggest you to turn
to Fortran 90 or 95 instead of FORTRAN 77), why not
use two different routines? The ENTRY statement can be
used to share local, saved, variables but I do not
see that this is necessary - you example does not
seem to reuse local variables (and while I have never
used the ENTRY statement myself) I think you can
see it as a sort of alternative for SUBROUTINE,
so declare the variables after the ENTRY statement
again.

As I said, ENTRY is not a _basic_ facility in FORTRAN 77.
Its use requires some care.

Regards,

Arjen

e p chandler

2005-05-23, 3:58 pm

vashwath@rediffmail.com wrote:
> There is no change in the result even after changing the prototype.Am
I
> making any mistake in the calling program please check. Below is the
> code of the calling program.
> PROGRAM MAIN
> REAL*8 ARR(20)
> REAL*8 TIME
> REAL*8 OUTPUT;
> INTEGER NRSTAT=112
>
>
> ARR(1)=10.0
> ARR(2)=3.0
> OUTPUT=0.0
>
>
> CALL GINITL(NRSTAT,ARR,TIME,OUTPUT)
>
>
> WRITE(*,*)OUTPUT
>
>
> STOP

You have two major problems here. First, OUTPUT has different types in
the calling program and in the subroutine. In the caller it is REAL*8
[1] which is (usually) the same as double precision. But in the
subroutine it is undeclared. Implicit typing [2] makes it real (single
precision). Fixing this involves adding a REAL*8 X after the other
declarations in the subroutine.

Second, the alternate entry point GINITL has its own argument list.
This has to match the CALL in the calling program. The list *does not*
have to be the same as the main entry point. The call needs to be CALL
GINITL(ARR,TIME,OUTPUT). You only need to declare the types and sizes
of the agruments once, at the top.

Notes: [2] Unless you have a declared type, or an IMPLICIT NONE - which
cancels default typing - variables that start with I through N default
to INTEGER, the rest default to REAL.

[1] One of the purposes of this newsgroup is to promote Fortran as
defined by various standards. REAL*8 is a non-standard but often
accepted synonym for DOUBLE PRECISION. Officially, it is frowned upon
in this newsgroup.

e-mail: epc8 at juno.com

Michael Metcalf

2005-05-23, 3:58 pm

"e p chandler" <epc8@juno.com> wrote in message
news:1116854338.144778.200540@o13g2000cwo.googlegroups.com...
>
> [1] One of the purposes of this newsgroup is to promote Fortran as
> defined by various standards.

I never knew that (and I've been a subscriber since 1991). It might be MY
purpose, but not that of the newsgroup (which I thought was more for
self-help).

>REAL*8 is a non-standard but often
> accepted synonym for DOUBLE PRECISION.

Correct.

>Officially, it is frowned upon
> in this newsgroup.
>

Officially??? I thought this was an informal group, one, however, where some
of us try to promote 'good' style and language use, but where others
nevertheless have other (deviant :-) ) views.

Regards,

Mike Metcalf

Richard E Maine

2005-05-23, 3:58 pm

In article <d6sqs0$f19$05$1@news.t-online.com>,
"Michael Metcalf" <metcalfmetcalf@compuserve.com> wrote:

> "e p chandler" <epc8@juno.com> wrote in message
> news:1116854338.144778.200540@o13g2000cwo.googlegroups.com...

>
> Officially???

The same thought occurred to me. Is the word "officially" being used as
a synonym for "unofficially" here? I suppose that would be consistent
with the widespread practice of using the word "literally" as a synonym
for "figuratively". That one drives me batty also. :-)

The problem here is that there is at least some chance that someone new
to the newsgroup might actually believe that the word "officially" means
what it says. At least the usual misuse of "literally" is so ludicrous
that there is little danger of it being misunderstood.

Perhaps it is just the editor in me that thinks communication is
facilitated by correct word usage, but I am generally pretty strict
about avoiding the word "officially" except when I mean....well...
"officially". The word might apply, for example, to something specified
by the standard. For example, I've probably referred to the TRs as
something like "official extensions to f95" because they are official
ISO documents.

I find that I'm much more often in the position of trying to make it
clear that my opinions are not official positions of any organization.
(P.S. They aren't. :-))

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

e p chandler

2005-05-23, 3:58 pm

Michael Metcalf wrote:
> "e p chandler" <epc8@juno.com> wrote in message
> news:1116854338.144778.200540@o13g2000cwo.googlegroups.com...
>
> I never knew that (and I've been a subscriber since 1991). It might
be MY
> purpose, but not that of the newsgroup (which I thought was more for
> self-help).
>

Perhaps it was not chartered that way but in effect it does so. Of
course this newsgroup is somewhat more lenient than others which can
get quite zealous about off-topic postings. As someone who still uses
non-standard constructs and occasionally posts them here, I'm not
afraid to have someone apply a judicious red pencil to my program
listings.

>
> Correct.
>
>
> Officially??? I thought this was an informal group, one, however,
where some
> of us try to promote 'good' style and language use, but where others
> nevertheless have other (deviant :-) ) views.
>
> Regards,
>
> Mike Metcalf

"Officially" was meant firmly tongue-in-ch

.

Elliot

e p chandler

2005-05-23, 8:57 pm

Richard E Maine wrote:
> In article <d6sqs0$f19$05$1@news.t-online.com>,
> "Michael Metcalf" <metcalfmetcalf@compuserve.com> wrote:
>
>
>
> The same thought occurred to me. Is the word "officially" being used
as
> a synonym for "unofficially" here? I suppose that would be consistent

> with the widespread practice of using the word "literally" as a
synonym
> for "figuratively". That one drives me batty also. :-)
>
> The problem here is that there is at least some chance that someone
new
> to the newsgroup might actually believe that the word "officially"
means
> what it says. At least the usual misuse of "literally" is so
ludicrous
> that there is little danger of it being misunderstood.
>

Then you must cringe when you see "virtual" or "virtually" as in "X
gets your windows virtually spot free."

See my other reply. Acutally it was said in jest. I thought that
"frowned upon" implied the hyperbole I intended.

glen herrmannsfeldt

2005-05-23, 8:57 pm

e p chandler wrote:

(someone wrote)

[color=darkred]
> Perhaps it was not chartered that way but in effect it does so. Of
> course this newsgroup is somewhat more lenient than others which can
> get quite zealous about off-topic postings. As someone who still uses
> non-standard constructs and occasionally posts them here, I'm not
> afraid to have someone apply a judicious red pencil to my program
> listings.

More than some other languages, Fortran is defined by its extensions.

That is, many of the features of each version were tested as extensions
on previous versions.

I would say the main reason off-topic posts are tolerated is that the
traffic level isn't so high. Even with the restrictions, comp.lang.c
gets a much larger number of posts per day. Miss a few days and you
will never catch up.

(I currently have 98365 unread posts in comp.lang.c.)

-- glen

e p chandler

2005-05-23, 8:57 pm

glen herrmannsfeldt wrote:
>
> I would say the main reason off-topic posts are tolerated is that the
> traffic level isn't so high. Even with the restrictions,
comp.lang.c
> gets a much larger number of posts per day. Miss a few days and you
> will never catch up.
>
> (I currently have 98365 unread posts in comp.lang.c.)
>
> -- glen

Also comp.lang.fortran is more of a catch-all than comp.lang.c, since
for "C" there are other newsgroups for specific versions and vendors.

Somewhat back on topic, I think we should be happy that there are new
people trying to learn the language, even though some of the code
posted here recently is "very dusty" and some OPs seem to lack an
understanding of programming fundamentals.

[flame on] The internet is great for getting almost instant answers.
But I do think something is lost here in not sitting down with another
person, listing and pencil in hand, to go over a piece of code. [flame
off]

Dave Weatherall

2005-05-24, 3:57 am

On Mon, 23 May 2005 16:10:33 UTC, Richard E Maine
<nospam@see.signature> wrote:

> In article <DTiotGxQ0bj6-pn2-Ihl3CUq9wlwN@dave2_os2.home.ours>,
> "Dave Weatherall" <djw-nothere@nospam.nohow> wrote:
>
>
>
> No, that is not correct in standard Fortran. Of course, as mentioned
> elsewhere in thread, the arguments from the CALL have to match the ENTRY
> called, but there is not requirement that the ENTRY and SUBROUTINE match.
>
> You are probably thinking of some of the f66 extensions for ENTRY. Prior
> to the standardization of ENTRY in f77, some compilers had f66
> extensions for ENTRY. Details of those extensions varied. IIRC, at least
> one variant didn't even put an argument list on the ENTRY at all,
> because the argument list was, by definition, the same as that of the
> subroutine or function.

You're correct Richard. I've fallen foul of the mis-match over the
years using the DEC compilers and it's a mantra now that I apply when
I use ENTRY. However, as you go on to point out, F66/77 does appear to
be the standard of code that he's trying to get working.

I obviously should have included CALLin the list of thing to check.

--
Cheers - Dave.

PS I'll have to fix my signature again to point out where I get into
trouble with the standard!

i.e. Caution VMS Fortran spoken here!

--
Cheers - Dave.

Sponsored Links