Re: suggestion for new intrinsic function: CONFORM

Beliavsky wrote:
When passing assumed shape arrays to procedures, typically the first
thing I do is check that the dimension are what I expect, in
particular that certain pairs of arguments conform, for example

subroutine foo(imat,y,z)
integer, intent(in) :: imat(:,:) ! (n1,n2)
real, intent(in) :: x(:,:) ! (n1,n2)
real, intent(out) :: z(:,:) ! (n1,n2)
if (size(imat,1) /= size(x,1) .or. size(imat,2) /= size(x,2) .or.
size(x,1) /= size(z,1) .or. size(x,2) /= size(z,2)) then
stop "unexpected dimenions in foo"
end if
! some code
end subroutine foo

I recommended this about two years ago (as part of a discussion
on generic programming). Except note that the bounds that must
conform are not always the same. Consider if IMAT, X, and Z
must be such that IMAT is the appropriate shape for the result
of matrix multiplying X and Z. Then Size(X,2) must be the
same as Size(Z,1), Size(IMAT,1) must match Size(X,1), and
Size(IMAT,2) must match Size(Z,2). I proposed:

Subroutine foo(imat, X, Z) ! I assume you really meant X
integer, inferred :: i, j, k
Real, intent(in) :: X(^i, ^j), Z(^j, ^k)
Real, intent(out) :: imat(^i, ^k)

The rule was that the ^ meant that the value was to be inferred
from the correponding property of the actual argument and that
all inferrences of the same name must yield the same value.
Since it's part of the procedure's declarations, the requirement
is in the procedure's interface and the compiler can often test
the constraint at compile-time when processing the caller.

Within the subroutine, the values of I, J, and K can otherwise
be used as named constants (whose value is that which was
inferred). So, they can be used to declare the bounds of some
local working arrays, or as loop limits, etc.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare


.

Relevant Pages

  • Re: Optional arguments in nested subroutines
    ... I would recommed always using PERSENT to check the ... OPTIONAL arguments before calliung the subroutine. ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: exit and reenter a subroutine
    ... Richard E Maine wrote: ... How do you exit a subroutine, then come back in the place where you ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: Basic question on local variable
    ... doesn't it make programs harder to ... I/O in a subroutine means putting the exit test in the middle ... if Fortran didn't permit them, ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: function : question on argument for output
    ... which it will not work as it would for a subroutine. ... but I bet if it came to a vote in the committee anytime ... Prior to about 1993 or so I would bet the vote would ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)
  • Re: Pointers to functions: Is this the right [f03] syntax?
    ... I can imagine that some will pass an entry point ... (With the change from NAME to XNAME since Glen's ... REF_SUB is it treated as anything other than a subroutine. ... no deficiencies and the other way is to make it so complicated ...
    (comp.lang.fortran)