[J3] Limitations of SELECT RANK?

[Malcolm Cohen]

It’s exactly identical to

 

   IF (RANK(arr)>=1 .AND. RANK(arr)<=3) CALL SUB(arr)

 

There is no “limitation” in SELECT RANK here.

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Clune, Thomas L. (GSFC-6101) via J3
Sent: Tuesday, October 20, 2020 1:24 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov>
Subject: [J3] Limitations of SELECT RANK?

 

I recall that when J3 was discussing one of the SELECT RANK papers for F2018,  I had asked whether something like this was possible:

 

Consider the construct:

 

SELECT RANK (arr)

RANK (1)

    CALL SUB(arr))

RANK (2)

    CALL SUB(arr))

RANK (3)

    CALL SUB(arr))

RANK DEFAULT

END SELECT RANK

 

where SUB() is a generic interface that is  suitably overloaded for the relevant ranks.

 

Could the feature be extended to allow the equivalent:

 

SELECT RANK (arr)

RANK(1:3)

    CALL SUB(arr)

RANK DEFAULT

END SELECT RANK

 

My memory is that there was a resounding “NO” in the room (presumably mostly by the vendors).       I would very much appreciate it if someone knowledgable about why that is not workable could respond on the thread below.       

 

https://github.com/j3-fortran/fortran_proposals/issues/185 

 

Or if preferred, they could respond to me directly and I can summarize in the GitHub discussion.  (With or without attribution depending on preference.)

 

Thanks,

 

- Tom

 

 

 

 

 

 

 

Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. Please see our Privacy Notice <https://www.nag.co.uk/content/privacy-notice>  for information on how we process personal data and for details of how to stop or limit communications from us.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20201020/24e4aeed/attachment.htm>