Prev: named common and subprogram names
Next: Why it is forbidden?
From: monir on 20 Dec 2009 20:56
On Dec 20, 6:42 pm, "e p chandler" <e...(a)juno.com> wrote:
> "monir" <mon...(a)mondenet.com> wrote
>
Richard wrote:
>> double precision ytmp(maxPln), y2tmp(maxPln)
>> call splined (x1a, ytmp , k, d1, dn, y2tmp)
>> SUBROUTINE SPLINEd(X, Y, N, YP1, YPN, Y2)
>> dimension X(N),Y(N),Y2(N)
> So y2tmp is dimensioned maxPln in the caller, but maxPln is not even
> passed to splined. Instead, k is passed and used (as the dummy named n)
> to dimension the y2 dummy argument.

e p chandler wrote:
>> SUBROUTINE SPLINTd(XA, YA, Y2A, N, X, Y)
>> implicit double precision (a-h,o-z)
>> dimension XA(N), YA(N), Y2A(N)
>is called with the assumption that XA, YA and Y2A are the same size, yet in
>several calling programs
>the passed arrays are dimensioned with DIFFERENT variables, which I expect
>are NOT constrained to be the same size.

But for 1D arrays, one DOES NOT have to pass the declared and actual
sizes to the called routines. Only the actual sizes.
The problem is most likely associated with the declaration/passing of
the 2D and 3D arrays.

Regards.
Monir


From: e p chandler on 20 Dec 2009 23:38

"monir" <monirg(a)mondenet.com> wrote in message
news:4c037cfc-2a89-44a4-93c5-e6a0c57b4974(a)g23g2000vbr.googlegroups.com...
On Dec 20, 6:42 pm, "e p chandler" <e...(a)juno.com> wrote:
> "monir" <mon...(a)mondenet.com> wrote
>
Richard wrote:
>> double precision ytmp(maxPln), y2tmp(maxPln)
>> call splined (x1a, ytmp , k, d1, dn, y2tmp)
>> SUBROUTINE SPLINEd(X, Y, N, YP1, YPN, Y2)
>> dimension X(N),Y(N),Y2(N)
> So y2tmp is dimensioned maxPln in the caller, but maxPln is not even
> passed to splined. Instead, k is passed and used (as the dummy named n)
> to dimension the y2 dummy argument.

e p chandler wrote:
>> SUBROUTINE SPLINTd(XA, YA, Y2A, N, X, Y)
>> implicit double precision (a-h,o-z)
>> dimension XA(N), YA(N), Y2A(N)
>is called with the assumption that XA, YA and Y2A are the same size, yet in
>several calling programs
>the passed arrays are dimensioned with DIFFERENT variables, which I expect
>are NOT constrained to be the same size.

But for 1D arrays, one DOES NOT have to pass the declared and actual
sizes to the called routines. Only the actual sizes.
The problem is most likely associated with the declaration/passing of
the 2D and 3D arrays.

Regards.
Monir

---> Yes, you can get away with DIMENSIONING the 1D arrays in your
subroutines to (1). Yes you can pass a 1D array that is actually longer than
that declared.

But why?

-- e





From: Richard Maine on 21 Dec 2009 00:01
monir <monirg(a)mondenet.com> wrote:

> But for 1D arrays, one DOES NOT have to pass the declared and actual
> sizes to the called routines. Only the actual sizes.

Which is why I said

>> Odds are that this one isn't actually a problem

> The problem is most likely associated with the declaration/passing of
> the 2D and 3D arrays.

Most likely. But note that I also said

>> but I take it as symptomatic of a style that
>> probably will cause problems elsewhere.

You should get in the habit of always coding correctly - not just
guessing when you have to and when you can get by without it. For a
start, you will guess wrong. For example, there are cases where you can
get in trouble with 1D arrays. Copy-in/copy-out can cause havoc with
incorrect dimensions even in 1D.

But more important is the human factor - that bit about getting in the
habit. If you are in the habit of being sloppy about things where they
don't matter, you will end up being sloppy about them elsewhere at
times, and it will bite you. This is almost inevitable.

That's why I stopped when I found one case. Even though odds are that
case isn't your problem

1. Maybe it is

2. But more importantly, it makes me guess that something like it
elsewhere is probably the problem.

If you can't take the trouble to be careful about such things yourself,
I decline to take my time to search further myself. I long ago
discovered the truth of the well-known adage that it takes less time to
do the job right in the first place than to deal with the consequences
of doing it sloppily. That is very true in programming. My personal
productivity sure went up a lot when I started making it a habit to
check every line for obvious errors when I wrote it in the first place.
One of those checks is making sure that arguments agree in such things
as dimensions. (F90 assumed shape makes it a lot easier to get such
things right, I might add).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: robin on 21 Dec 2009 18:46
monir wrote in message ...
>Thank you ALL for your precise and helpful replies.
>The answer to my subject question is clearly: "YES, one can".
>
>1) Shortly before retrieving your replies and being unsure what the
>answer would be, I tried a Parameter statement in the example Sub Test
>() ; specifying the maximum anticipated subscripts "m" and "n" for the
>local arrays.
>I got different results, which is very confusing, and I've been
>working on the problem since then !!!
>
>2) OP example:
> Subroutine Test(w,m,n) !m=10, n=20
> integer m,n
> real w
> real x(m)
> real y(m,n)
> real z(m,m,n)
>!.....................................
> w = whatever
>!....................................
> return
> end subroutine Test
>
>
>Modified:
> Subroutine Test_2(w)
> integer m,n, maxm, maxn
> Parameter (maxm=30, maxn = 30)
> real w
> real x(maxm)
> real y(maxm,maxn)
> real z(maxm,maxm,maxn)
>!.....................................
> w = whatever
>!....................................
> return
> end subroutine Test_2
>
>3) In the real situation (actual code), the individual routines works
>fine in isolation, but not in the following combination, which may
>suggest that the variable arrays are not manipulated/passed correctly
>(dimension-wise) and perhaps the problem is not a dynamic array issue
>after all. Or is it ??

The above code does not use dynamic arrays.

These issues were discussed at length and explained in the post
"Could this result in array distortion"
that you inititiated.


From: robin on 22 Dec 2009 05:53
e p chandler wrote in message ...
>
>"monir" <monirg(a)mondenet.com> wrote in message
>news:4c037cfc-2a89-44a4-93c5-e6a0c57b4974(a)g23g2000vbr.googlegroups.com...
>On Dec 20, 6:42 pm, "e p chandler" <e...(a)juno.com> wrote:
>> "monir" <mon...(a)mondenet.com> wrote
>>
>Richard wrote:
>>> double precision ytmp(maxPln), y2tmp(maxPln)
>>> call splined (x1a, ytmp , k, d1, dn, y2tmp)
>>> SUBROUTINE SPLINEd(X, Y, N, YP1, YPN, Y2)
>>> dimension X(N),Y(N),Y2(N)
>> So y2tmp is dimensioned maxPln in the caller, but maxPln is not even
>> passed to splined. Instead, k is passed and used (as the dummy named n)
>> to dimension the y2 dummy argument.
>
>e p chandler wrote:
>>> SUBROUTINE SPLINTd(XA, YA, Y2A, N, X, Y)
>>> implicit double precision (a-h,o-z)
>>> dimension XA(N), YA(N), Y2A(N)
>>is called with the assumption that XA, YA and Y2A are the same size, yet in
>>several calling programs
>>the passed arrays are dimensioned with DIFFERENT variables, which I expect
>>are NOT constrained to be the same size.
>
>But for 1D arrays, one DOES NOT have to pass the declared and actual
>sizes to the called routines. Only the actual sizes.
>The problem is most likely associated with the declaration/passing of
>the 2D and 3D arrays.
>
>Regards.
>Monir
>
>---> Yes, you can get away with DIMENSIONING the 1D arrays in your
>subroutines to (1). Yes you can pass a 1D array that is actually longer than
>that declared.

That was a mid-1960s hack for adjustable dimensions - long since
obsolete.

Monir was not talking about that.

For adjustable dimensions (F77) the array is dimensioned
with a variable for its bound, and that variable and the array
are dummy arguments.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: named common and subprogram names
Next: Why it is forbidden?