[J3] [EXTERNAL] Re: Limitations of SELECT RANK?
Bill Long
longb at cray.com
Tue Oct 20 10:59:58 EDT 2020
> On Oct 20, 2020, at 8:10 AM, Reuben D. Budiardja via J3 <j3 at mailman.j3-fortran.org> wrote:
>
>
> Can the compiler not expand this appropriately at compile time so that the appropriate resolution can be done at compile time?
Maybe, if the compiler has the -fmind-read option, and is willing to overlook the syntax violation [RANK(1:3) is not conforming]. The -fmind-read option is often (usually indirectly) requested. However, there was an ancient language named PL/1 that had this capability and the results were sometimes catastrophic when the compiler made the wrong guess. Compiler writers and language designers learned a lesson.
>
> In Tom's original example, the two constructs are equivalent.
No, not the way the standard is written. RANK(1:3) has no meaning specified in the standard. I think what you are wanting here is a new syntax rule that allows multiple ranks to be specified (all different - no repeats allowed) and have the semantics be specified so that the syntax represents multiple RANK statements, one for each of the specified ranks, and with the identical BLOCK replicated for each. In the end, the compiler needs to see only ONE rank value for a particular block. Otherwise, the whole point of SELECT RANK is missed.
> So if compiler can do the first construct in principle it can do the second one, except the second one is simpler / easier for the programmer to write.
>
> Or am I missing something obvious?
>
> Thanks,
> Reuben
>
> On 10/19/2020 11:33 PM, Bill Long via J3 wrote:
>> OK, we agree then.
>> Cheers,
>> BIll
>>> On Oct 19, 2020, at 10:13 PM, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> wrote:
>>>
>>> My point is that the suggested
>>> SELECT RANK(ARR)
>>> RANK(1:3)
>>> CALL SUB(ARR)
>>> END SELECT
>>> ***IS IDENTICAL TO***
Depends on how you define the (newly invented) semantics for RANK(1:3).
>>> IF (RANK(ARR)<=1 .AND. RANK(ARR)<=3) CALL SUB(ARR)
Probably intended RANK(ARR) >= 1.
>>> ********
>>> IN BOTH CASES IF GENERIC RESOLUTION BASED ON THE RANK OF ARR IS REQUIRED IT CANNOT BE DONE AT COMPILE TIME!
>>> Caps Lock got stuck but I’m sure you get the point. SELECT RANK doesn’t buy you anything unless you actually select a rank. Not several ranks, *A* rank.
Absolutely. If you do not have a compile-time-known single value for the rank, the SELECT RANK construct is useless.
Cheers,
Bill
>>> Cheers,
>>> --
>>> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>>> From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Bill Long via J3
>>> Sent: Tuesday, October 20, 2020 12:07 PM
>>> To: General J3 interest list <j3 at mailman.j3-fortran.org>
>>> Cc: Bill Long <longb at cray.com>
>>> Subject: Re: [J3] Limitations of SELECT RANK?
>>> If you call generic SUB without knowing the rank of arr at compile time, which of the 3 specifics do you call?
>>>
>>> I don’t see how the IF version could work.
>>>
>>>
>>>
>>>> On Oct 19, 2020, at 9:38 PM, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> wrote:
>>>>
>>>> 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 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.
>>>
>>> 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
>> 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
>
> --
> Reuben D. Budiardja, Ph.D.
> reubendb at ornl.gov | (865) 576-9519
> National Center for Computational Sciences
> Oak Ridge National Laboratory
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
More information about the J3
mailing list