Hello;

1) Given arrays "xa" and "ya" of length "m" containing a tabulated
function,  the following simplified/abbreviated code shows the 1st
call passing the first 3 elements of the arrays, while the 2nd call
passing the last 3 elements:
(F77, g95):

  Program main
  Parameter (m=30)
  dimension xa(m), ya(m)
!.........my code1.........
  Call DerivPol (xa, ya, 3, xa(1), d1)
  Call DerivPol (xa(m-2), ya(m-2), 3, xa(m), dn)

!.........my code2.........
  Stop

!*******************************************
  Subroutine DerivPol (xa, ya, n, x, dy)
!*******************************************
c Given arrays xa and ya, each of length n, and given a value x,
c this routine returns a value dy.

   Parameter (nmax=30)
   dimension xa(n),ya(n),cof(nmax),pd(nmax)
!.........my code3.........
   Return
   End

2) The above 1st Call DerivPol() is OK.  How about the 2nd call ??
Do you see any potential problem with the second call ??

3) Now, if the arrays "xa" and "ya" are 2D dimensioned "nmax,mmax" in
main and its routine, and the necessary declarations and changes to
the arguments are made accordingly to accommodate the additional
dimension.
One can easily (I think) modify the above 1st Call to pass a subarray,
say 4 (rows) by 3 (col) elements at the top left of the arrays.
But can one similarly extend the 2nd Call to pass a subarray 4 by 3 at
the bottom right of the arrays ??
My concern is primarily the conflict between matrix definition and the
arrays elements storage sequence!!
How would write the 2nd call in this 2D case ??
(I should be able to extend it to the 3D arrays case)

Your suggestions and advice would be greatly appreciated.
Monir

monir <monirg@mondenet.com> wrote:
 
> 1) Given arrays "xa" and "ya" of length "m" containing a tabulated
> function,  the following simplified/abbreviated code shows the 1st
> call passing the first 3 elements of the arrays, while the 2nd call
> passing the last 3 elements:
> (F77, g95):
 
>  Program main
>  Parameter (m=30)
>  dimension xa(m), ya(m)
> !.........my code1.........
>  Call DerivPol (xa, ya, 3, xa(1), d1)
>  Call DerivPol (xa(m-2), ya(m-2), 3, xa(m), dn)
 
> !.........my code2.........
>  Stop
 
> !*******************************************
>  Subroutine DerivPol (xa, ya, n, x, dy)
> !*******************************************
> c Given arrays xa and ya, each of length n, and given a value x,
> c this routine returns a value dy.
 
>   Parameter (nmax=30)
>   dimension xa(n),ya(n),cof(nmax),pd(nmax)
> !.........my code3.........
>   Return
>   End
 
> 2) The above 1st Call DerivPol() is OK.  How about the 2nd call ??
> Do you see any potential problem with the second call ??

Looks fine to me.  More usual, the dummy arrays would be 
dimensioned (*) instead, but (n) might allow bounds checking
on the specified bounds.  (Which may or may not match the actual
argument bounds.)
 
> 3) Now, if the arrays "xa" and "ya" are 2D dimensioned "nmax,mmax" in
> main and its routine, and the necessary declarations and changes to
> the arguments are made accordingly to accommodate the additional
> dimension.

> One can easily (I think) modify the above 1st Call to pass a subarray,
> say 4 (rows) by 3 (col) elements at the top left of the arrays.

If the elements are contiguous, yes.  That would require all except
the rightmost subscript to be equal in the dummy and actual arguments.

> But can one similarly extend the 2nd Call to pass a subarray 4 by 3 at
> the bottom right of the arrays ??

Same requirements as for the top.

> My concern is primarily the conflict between matrix definition and the
> arrays elements storage sequence!!
> How would write the 2nd call in this 2D case ??
> (I should be able to extend it to the 3D arrays case)

Well, one way is to use assumed shape which can process non-contiguous
arrays fairly easily.  (Though possibly slower due to cache effects.)

The Fortran 77 way is to pass both the actual dimension for all 
except the rightmost, in addition to the subarray dimensions.
(Which still works in later versions as assumed size or explicit
size.)

-- glen

On Nov 16, 12:56=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:
> monir <mon...@mondenet.com> wrote:
> - Show quoted text -

Glen;

Thank you for your prompt and helpful reply.

Regards.
Monir

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message news:hdqpiq$li6$1@naig.caltech.edu...
| monir <monirg@mondenet.com> wrote:
|
| > 1) Given arrays "xa" and "ya" of length "m" containing a tabulated
| > function,  the following simplified/abbreviated code shows the 1st
| > call passing the first 3 elements of the arrays, while the 2nd call
| > passing the last 3 elements:
| > (F77, g95):
|
| >  Program main
| >  Parameter (m=30)
| >  dimension xa(m), ya(m)
| > !.........my code1.........
| >  Call DerivPol (xa, ya, 3, xa(1), d1)
| >  Call DerivPol (xa(m-2), ya(m-2), 3, xa(m), dn)
|
| > !.........my code2.........
| >  Stop
|
| > !*******************************************
| >  Subroutine DerivPol (xa, ya, n, x, dy)
| > !*******************************************
| > c Given arrays xa and ya, each of length n, and given a value x,
| > c this routine returns a value dy.
|
| >   Parameter (nmax=30)
| >   dimension xa(n),ya(n),cof(nmax),pd(nmax)
| > !.........my code3.........
| >   Return
| >   End
|
| > 2) The above 1st Call DerivPol() is OK.  How about the 2nd call ??
| > Do you see any potential problem with the second call ??
|
| Looks fine to me.  More usual, the dummy arrays would be
| dimensioned (*) instead, but (n) might allow bounds checking
| on the specified bounds.  (Which may or may not match the actual
| argument bounds.)

The purpose of not using (*) and instead of using (n)
for the bound is to enable PRINT *, xa, ya to work. 

On Nov 17, 3:59=A0am, "robin" <robi...@bigpond.com> wrote:
> "glen herrmannsfeldt" <g...@ugcs.caltech.edu> wrote in messagenews:hdqpiq=
$li6$1@naig.caltech.edu...
> | monir <mon...@mondenet.com> wrote:

> "robin" <robi...@bigpond.com> wrote:
> The purpose of not using (*) and instead of using (n)
> for the bound is to enable PRINT *, xa, ya to work.

Good point.
I generally try  to avoid the use of (*) as a length specifier.
Besides, I don't think it can be used in multidimensional arrays, at
least in F77.  Correct ??

Regards.
Monir

monir <monirg@mondenet.com> wrote:
(snip)

> I generally try  to avoid the use of (*) as a length specifier.
> Besides, I don't think it can be used in multidimensional arrays, at
> least in F77.  Correct ??

The * can be specified for the last (rightmost) subscript of
a multidimension array.  Also, the number of dimensions (rank)
does not have to agree with that of the actual argument.

-- glen

On Nov 17, 1:22=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> monir <mon...@mondenet.com> wrote:
>
> The * can be specified for the last (rightmost) subscript of
> a multidimension array. =A0Also, the number of dimensions (rank)
> does not have to agree with that of the actual argument.
>

Glen;

1) You raised an extremely interesting point, which might lead to the
solution of a problem I'm stuck with for quite some time now,
basically "suspected array distortion" somewhere in a (large and
complex) program and unable to locate exactly where!!
No compiler errors, no out-of-bound, no warnings, etc., just mixed
results for very simplified scenarios.

2) If I have arrays x(10,20,30) and y(5,25) passed as arguments to Sub
Test(xx,yy,...) and if I interpret your statement correctly regarding
the use of * and the no. of dimensions, then in Sub Test() any of the
following declarations, depending on the function of the sub, would be
acceptable: (F77, g95)

!...real xx(10,20)
!...real xx(10,20,*)
!...real yy(5,*)
!...real yy(5)
!...(others?)
Correct ??

3) If you concur, then I should be able to remove unnecessary
"rightmost" dim from similar declarations throughout the program or
replace them with *, as the case maybe, and thus narrow down the
search of arrays distortion.

Regards.
Monir

In article <hdqpiq$li6$1@naig.caltech.edu>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

> Well, one way is to use assumed shape which can process non-contiguous
> arrays fairly easily.  (Though possibly slower due to cache effects.)
> 
> The Fortran 77 way is to pass both the actual dimension for all 
> except the rightmost, in addition to the subarray dimensions.
> (Which still works in later versions as assumed size or explicit
> size.)

The above "cache effect" comment applies equally to both situations.  
That is, it is due to the effect of noncontiguous addressing on the 
hardware rather than to the differences in the two features of the 
language.

Also, on some compilers the assumed shape approach is more flexible.  
For example, a TRANSPOSE() expression in an actual argument might be 
done simply with dope vector manipulation rather than creating a copy, 
while the f77 approach would always require an explicit copy.  You can 
verify this with the (nonstandard) loc() function; it surprised me the 
first time I saw a compiler do this.

$.02 -Ron Shepard