(j3.2006) an intrinsic for SORT()

Clune, Thomas L. GSFC-6101 thomas.l.clune
Tue Feb 6 14:14:08 EST 2018


>> On Feb 6, 2018, at 12:07 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:
>> 
>> On Tue, 2018-02-06 at 16:24 +0000, Bill Long wrote:
>>> So the rationale for the intrinsic is purely one of convenience. 
>> 
>>> And the code is not that hard to write.  It?s unclear if providing an
>>> intrinsic for this is worthwhile.
>> 
>> 
>>> Certainly as a first pass,  we should look at only a single-image
>>> sort routine. 
>> 
>> Where's the compelling use case for this?
>> 
>> As a first pass, we should ignore this.  There are many things that are
>> more important and that can't be done with already-existing library
>> routines.  Let's not waste our time re-inventing the wheel.
> 

Hmm.  I somehow missed Van?s response in this thread ?

I _never_ said this item was a priority.   Nor was a use case provided.   I was merely checking in to see if the issue had arisen before and was rejected for reasons that I cannot anticipate.         In some sense use cases for this are ubiquitous and each is on its own relatively non compelling.   It is merely a common step in many different algorithms.    I?ll certainly collect some of those when creating the paper. 

No doubt this feature will _not_ be a top priority on anyone?s list (at least within the committee), but it also will be relatively low-cost both in terms of adding the words to the standard and in terms of vendor effort to implement.    I strongly suspect that we will include a number of ?small/easy? features as packing peanuts around the few ?big? features that get added.   This fits the pattern of many intrinsics.

- Tom



> On Feb 6, 2018, at 1:52 PM, Bill Long <longb at cray.com> wrote:
> 
> 
>> On Feb 6, 2018, at 12:07 PM, Van Snyder <van.snyder at jpl.nasa.gov> wrote:
>> 
>> On Tue, 2018-02-06 at 16:24 +0000, Bill Long wrote:
>>> So the rationale for the intrinsic is purely one of convenience. 
>> 
>>> And the code is not that hard to write.  It?s unclear if providing an
>>> intrinsic for this is worthwhile.
>> 
>> 
>>> Certainly as a first pass,  we should look at only a single-image
>>> sort routine. 
>> 
>> Where's the compelling use case for this?
>> 
>> As a first pass, we should ignore this.  There are many things that are
>> more important and that can't be done with already-existing library
>> routines.  Let's not waste our time re-inventing the wheel.
> 
> 
> I?m happy with doing nothing here.  But, IF we do something, start with a single-image routine only. 
> 
> The advantage of an intrinsic is that it provides a portable calling sequence.  And the user does not need to be concerned about finding and linking a library.  We have other, similar, intrinsics.  MATMUL, for example.  Certainly the ?use case? of sorting a numeric array exists.  The question is whether the advantages of making that operation an intrinsic is sufficient motivation for making this a feature. 
> 
> Cheers,
> Bill
> 
>> 
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> Bill Long                                                                       longb at cray.com
> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
> Bioinformatics Software Development                      fax:  651-605-9143
> Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3




More information about the J3 mailing list