Prev: COLLEGE HOT GIRLS FUNNY GAMES
Next: how to get the output of call system in a variable
From: robin on 3 Mar 2010 07:16
Nathan wrote in message <6d5dfe3e-eaed-41d5-92c5-98e0bbadf88a(a)k2g2000pro.googlegroups.com>...
>I am having a problem passing arrays into a subfunction.
>
>Here is how I call my subfunction

It's a subroutine.

>CALL MIX1(NCOMP,CONC,TCFG,PCG,ACENG,TCMXFFG,PCMXFG,ACENMXFG,IER)
>
>NCOMP is an integer value, stating the number of components to pay
>attention to (max of 10)

What is its value?

>CONC, TCFG, PCG, and ACENG are all defined to be arrays of length 10
>I.E.:
>DIMENSION CONC(10), TCFG(10), PCG(10), ACENG(10)
>
>TCMXFFG, PCMXFG, and ACENMXFG are single value variables that are
>returned from MIX1, and IER is an array of length 7
>
>When I call MIX1 as above, only the first value of each array is being
>passed in, which is returning erroneous values for each output (except
>for IER, which catches the error information).
>
>I have been searching around for a while to no avail as to how to
>remedy my problem.
>
>Any help would be appreciated. If you need more information, I will be
>glad to supply it for you (if I can).


1. Where are the declarations for the variables?
2. What are the values of those variables?
3. Where is the code for MIX1?


From: Nathan on 3 Mar 2010 12:05
I'm at school right now, so I don't have the appropriate code to show
with me.
MIX1 is a subROUTINE (sorry for the mixup... it was a long day
yesterday) within a different file.
When I get to work later, I will try to supply the source for MIX1
(and hopefully it isn't dependent upon other subroutines...) and
whatever else is needed to help sort this out.
The declarations for CONC,TCFG,PCG,ACENG are at the beginning of the
subroutine that is calling MIX1. They are declared as I have already
shown:
DIMENSION CONC(10), TCFG(10), PCG(10), ACENG(10)
NCOMP is passed from the main function, taken as input from the user.
CONC is derived FROM input from the user, and so are TCFG,PCG and
ACENG.

An example of what I mean when I say that only the first value of the
arrays are being passed in are as such:

CONC is an array containing the values (depending on input from the
user...): .79 and .21
Off the top of my head, I don't know the values of TCFG,PCG, and ACENG
relative to these values...

Anyways, while debugging I see the CONC array has these values stored
within. Once inside the MIX1 subroutine, the corresponding variable
for CONC (which will be shown later to be XIN) only contains the
value .79 and is of length 1.

This probably still isn't helping, so I'll stop right here and come
back when I have source code...

Thanks for taking a look, and sorry for not providing enough
information (as well as mixing up subroutine with "subfunction")


-Nathan
From: James Van Buskirk on 3 Mar 2010 12:17
"Nathan" <ngreco32(a)gmail.com> wrote in message
news:cf89482d-8c05-48ee-b61f-1bb6c0a68ed0(a)m27g2000prl.googlegroups.com...

> This probably still isn't helping, so I'll stop right here and come
> back when I have source code...

When you see the source code for MIX1, it probably will have a line
that looks like:

DIMENSION CONC(1), TCFG(1), PCG(1), ACENG(1)

Change this to:

DIMENSION CONC(*), TCFG(*), PCG(*), ACENG(*)

or:

DIMENSION CONC(NCOMP), TCFG(NCOMP), PCG(NCOMP), ACENG(NCOMP)

This is a situation where the compiler may be able to understand old
f66 code but not the debugger.

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


From: Richard Maine on 3 Mar 2010 12:26
Nathan <ngreco32(a)gmail.com> wrote:

> I'm at school right now, so I don't have the appropriate code to show
> with me.

That's going to severely limit the help available.

> Anyways, while debugging I see the CONC array has these values stored
> within. Once inside the MIX1 subroutine, the corresponding variable
> for CONC (which will be shown later to be XIN) only contains the
> value .79 and is of length 1.

So your evidence is based only on the debugger? It is quite plausible
that this might just be a debugger issue then. That's particularly so
if, for one thought, the dummy array is declared assumed size. In that
case, most debuggers probably won't have the information about what the
size is and might just use 1. It is even more likely if the code
actually dimensions the dummy with size 1, as was a common f66-era hack,
before assumed size was available. (Many programmers continued using
that hack out of habit well into f77 days.) Have you tried actually
printing out the values in the subroutine?

I begin to wonder if you might not even be asking the real question. I'm
imagining that you were debugging some unspecified problem and ran into
this oddity, getting distracted by it. If you are seeing nothing but a
debugger oddity with assumed size, then the whole question is probably
irrelevant to whatever the actual bug was.

That's just a pretty wild guess on my part. I could be way off. But it
does match the (very little) data given and would be a textbook case of
asking for help with what you thought the problem was, which so often
turns out to have nothing to do with the real problem. That is typical
of many people asking for debugging help - not just you. If there were a
FAQ for the newsgroup, answer number 1 on it would probably be "show us
the data instead of your conclusions."

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
 | 
Pages: 1
Prev: COLLEGE HOT GIRLS FUNNY GAMES
Next: how to get the output of call system in a variable