(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