Array puzzle



I'm a relatively inexperienced Fortran programmer, so please go gently.

While looking through the IVF documentation, I learned that it's inefficient to pass an assumed shape or allocatable array to a procedure, inside of which it's referenced as a non-deferred shape array. Further reading discourages using assumed size arrays. So I looked through the very old code I'd been using for some time, and found this:

The original code had basically explicit shape arrays, passed into procedures as automatic or assumed-size arrays. Example:

Program Old
REAL A
INTEGER N
DIMENSION A(30)

N=6
.. . .

CALL P1(A)
CALL P2(A,N)
END

SUBROUTINE P1(B)
REAL B
DIMENSION B(*)

B(23) = . . .
END

SUBROUTINE P2(B,N)
REAL B
INTEGER N
DIMENSION B(N,*)

B(3,4) = . . .
END

Some time back I made array A in the main program allocatable with rank 1. With no other changes, everything works ok. But recent attempts to conform to the IVF guidelines have been a failure. First off, some of these arrays are large, so it's undesirable to make unnecessary copies. The IVF documentation says that if an assumed shape or allocatable array is passed to a procedure where it's referenced as an explicit shape or assumed size array, a temporary array is created. So I decided to try sending the array in as an assumed shape array and declaring it that way inside the procedure also.

It works fine for procedures like P1, where the rank of the array inside the procedure is the same as the array in the calling program. The problem comes with subroutine P2 in the example above, where the rank of the array inside the procedure is different from the rank of the array passed in by the calling program. I made INTERFACE blocks, but found that the rank in the interface block has to match both the rank inside the procedure and the rank of the array in the calling program or procedure. If I simply make all the ranks one, an error occurs at the B(3,4) statement.

Is there a way to do this, that is, to pass an assumed shape array into a procedure where the array inside is a different rank than in the calling procedure? Even if the effort of changing things isn't worth the trouble, I'd like to learn more about this.

Thanks!

Roy Lewallen


.



Relevant Pages

  • Part 4 of Short Steps Toward Generic Programming: KIND Genericity
    ... In this part I will again be discussing a feature that has been ... KIND and select the appropriate instance at compile-time in the ... Assumed Rank Arrays ... argument that don't require knowledge of the rank of the array. ...
    (comp.lang.fortran)
  • can this code be improved
    ... // the new array containing unique numbers only ... int number = 0; ... boolean dupLocated=false; ... Rank 1 number is 43 ...
    (comp.lang.java.programmer)
  • Re: Ranking Without Sorting
    ... you have just reinvented the rank sort. ... >> 'rank' array you want. ... >> Doing a 'heap sort', for example, where the heap holds the index into ...
    (comp.programming)
  • Re: Display the max, then the next down, then the next down, etc.
    ... > I just had to fix a couple of cell references. ... > the ROWwill give you the second lowest rank, and so on down the line. ... > The IF/ROW functions will return an array to feed into LARGE. ... The COUNTIF will count only one ...
    (microsoft.public.excel.misc)
  • Re: Ranking Without Sorting
    ... >> contradicted in my first post where I gave an example of how to rank ... > It seems quite clear to me that your 'ranking' array contains the exact ... The ranking array is completed from left to right as it might in a selection sort and unlike insertion sort. ...
    (comp.programming)