[J3] [EXTERNAL] Re: Limitations of SELECT RANK?

[Bill Long]

Or, using the proposed template syntax:

template subroutine add(b1, b2, b3)
  real,intent(inout) :: b1(..)
  real,intent(in) :: b2(..)
  real,intent(in) :: b3(..)

  b1 = b1 + b2 + b3

end subroutine add

The compiler would generate an actual routine with a mangled name and based on the rank and bounds of the actual arguments at the CALL site. (And, in this case, likely inline the result.) 

Cheers,
BIll


> On Oct 20, 2020, at 2:12 PM, Clune, Thomas L. (GSFC-6101) via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> And this is where I see a template parameter as being a win.   If we know the ranks will all be the same, then we ought to be able to write the routine in a rank agnostic manner and sidestep the SELECT RANK clause entirely.
> 
> Not intending to imply syntax, but making it look C++-ish to be hopefully obvious in intent:
> 
> SUBROUTINE ADD<n>(b1,b2,b3)
>   REAL, RANK(n), INTENT(INOUT) :: b1
>   REAL, RANK(n), INTENT(IN) :: b2
>   REAL, RANK(n), INTENT(IN) :: b3
> 
>   b1 = b1 + b2 + b3
> 
> END SUBROUTINE ADD
> 
> (An alternative interface would be to use BOUNDS for declaring b2 and b3 which would guarantee that the shapes of the arrays are the same.)
> 
> - Tom
> 
> PS Feeling guilty - if I’d known the thread would have played out in this manner, I would have posted in the forum.   
> 
> 
> 
> 
>> On Oct 20, 2020, at 2:58 PM, Mark LeAir via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>> To give a little better context to Tom's question.
>> 
>> On the fortran-proposals Github, we were discussing select rank and how one would need to generate nested select ranks equal to the number of assumed rank arrays in an array expression.
>> 
>> For example, let's say we want to compute b1 = b1 + b2 + b3 (where b1, b2, and b3 are all assumed rank arrays). Let's also say the programmer knows that the rank of the arrays must be rank 2 or 3. Today, they would have to write something like the following:
>> 
>> subroutine add_arrays(b1, b2, b3)
>> 
>> real :: b1(..), b2(..), b3(..)
>> 
>> select rank (b1)
>> rank(2)
>>  select rank(b2)
>>    rank(2)
>>      select rank(b3)
>>        rank(2)
>>          b1 = b1 + b2 + b3
>>       rank default
>>         error stop 'expected rank 2 for b3'
>>      end select
>>    rank default
>>      error stop 'expected rank 2 for b2'
>>    end select
>> rank(3)
>>  select rank(b2)
>>    rank(3)
>>      select rank(b3)
>>        rank(3)
>>          b1 = b1 + b2 + b3
>>        rank default
>>          error stop 'expected rank 3 for b3'
>>      end select
>>      rank default
>>        error stop 'expected rank 3 for b2'
>>   end select
>> rank default
>>   error stop 'unexpected rank for b1'
>> end select
>> 
>> end subroutine add_arrays
>> 
>> As you can see, the number of nested ranks grow with the number of expected ranks.  Since a common case is for all assumed rank arrays in an expression to have the same rank, I suggested the following extension:
>> 
>> Select rank could be extended to evaluate a list of assumed rank arrays. If they are all the same rank, then execution branches to that rank case. Otherwise, execution branches to RANK DEFAULT (if provided) or to the end of the select rank construct. If RANK DEFAULT is provided, then the programmer could provide either one or more nested select ranks or do something else (e.g., issue an error and abort).
>> 
>> The following shows how the above nested rank example could be simplified with the proposed extension:
>> 
>> select rank (b1, b2, b3)
>> rank (2)
>> b1 = b1 + b2 + b3
>> rank (3)
>> b1 = b1 + b2 + b3
>> rank default
>> error stop 'unexpected rank'
>> end select
>> 
>> We could then take the extension a step further and allow the following:
>> 
>> select rank (b1, b2, b3)
>> rank (2:3)
>> b1 = b1 + b2 + b3
>> rank default
>> error stop 'unexpected rank'
>> end select
>> 
>> Because all arrays must have the same rank in the rank cases, the code that the processor must generate is simplified. It doesn't have to unfold any nested select rank cases. It just needs to generate a rank case (inline) for each alternative in the rank list. A processor could also just invoke one or more rank agnostic runtime routines to perform the arithmetic operations. This would further simplify the generated code as the processor does not have to unfold any rank cases. The runtime routines may also be acceptably slower compared to the unfolded version. Obviously, that would be for the implementer to determine which generated code approach to use.
>> 
>> -Mark
>> 
>> 
>> -----Original Message-----
>> From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Steidel, Jon L via J3
>> Sent: Tuesday, October 20, 2020 9:21 AM
>> To: General J3 interest list <j3 at mailman.j3-fortran.org>
>> Cc: Steidel, Jon L <jon.l.steidel at intel.com>
>> Subject: Re: [J3] [EXTERNAL] Re: Limitations of SELECT RANK?
>> 
>> External email: Use caution opening links or attachments
>> 
>> 
>> Tom wrote:
>> We are seeing that common use cases for SELECT RANK have duplicate text.      Aside from generic resolution, there are also cases involving whole array arithmetic.   For these cases,  the shorthand in my example is not just convenient for the coder, but is also a means to reduce errors that can happen when a subsequent change is only propagated to a subset of the RANK clauses.   Granted, this is the weakest case of code duplication, as the duplicates would all line up next to each other in a single file.
>> End Tom
>> 
>> While there may be use cases that have duplicate text in multiple SELECT RANK case blocks, many involving whole array arithmetic, the code generated for each of the blocks is very different due to the difference in the array ranks between the two blocks.  The compiler would have to replicate the block for each possible rank and generate a separate block for each rank.  The ranks specified in the rank selector would need to be constant for this to happen, they could not be variable or values evaluated at runtime.
>> 
>> -jon
>> 
>> 

Bill Long                                                                       longb at hpe.com
Engineer/Master , Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Hewlett Packard Enterprise/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425