[J3] [EXTERNAL] Re: Proposals for new intrinsic procedures

[Brad Richardson]

Tom,

I agree having *decided* on a name is not particularly important at this stage, but I have to put something in the paper. Might as well put something that's had some thought.

Whilst I think a *parallel implementation* of scan would be desirable, `co_scan` seems a bit odd at first blush. For example

program test_co_scan
implicit none
integer :: i
i = this_image()
sync all
call co_scan(i, plus)
print *, "i = ", i, " on image ", this_image()
contains
pure function plus(x, y) result(total)
integer, intent(in) :: x, y
integer :: total
total = x + y
end function
end program

Output expected to be (with lines in random order)

i = 1 on image 1
i = 3 on image 2
i = 6 on image 3
i = 10 on image 4

Not that you couldn't imagine a use case for wanting the result of a scan operation to be distributed across images. As suggested to me by Brandon Cook, you could use it to calculate the offsets for having each image read/write its unequally sized portion of data from/into a shared resource (i.e. a file).

Bill,

Is the "Applications" section of the Wikipedia page sufficient for use cases here? (https://en.wikipedia.org/wiki/Prefix_sum) I could include a reference to that in the paper if people feel it warranted. And for the IEEE-754 functions, is wanting Fortran to be able to say it fully supports that standard not sufficient motivation for them? Not to be dismissive of the idea that we should have motivation/use-cases for wanting to introduce new features/intrinsics (I'm in favor of that), but these seemed like a no-brainer if someone were inclined to put in the effort.

Regards,
Brad

On Fri, 2023-01-06 at 13:45 +0000, Clune, Thomas L. (GSFC-6101) wrote:

> Brad – I think it is premature to worry about precise names. As Bill suggested, the focus should be on use cases. If we move forward, JOR can compose a straw vote at the appropriate stage.
>
> Bill – scan() is something like sort() in that you can spend a lot of time writing HPC software and never encounter the need for either of them. But there are compelling use cases out there. A serial implementation is almost trivial, but efficient parallel implementations have a healthy amount of literature. In that regard the COSCAN would be a higher priority in my book. But even within a single image, a vendor might use threads to implement a local scan.
>
> My encounter with scan() occurred ~4 years ago when I was working on a simulation that needed to know the amount of mass in overlapping cells of randomly aligned grids. With scan() I only needed to know the location of the top and bottom of each intersection. For just two such grid this would not be a win, but there are O(20) grids so that the scan() calculation is amortized. But I’m sure there are much better/clearer use cases out there.
>
> Cheers,
>
> - Tom
>
> From:J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
> Reply-To: j3 <j3 at mailman.j3-fortran.org>
> Date: Thursday, January 5, 2023 at 6:35 PM
> To: j3 <j3 at mailman.j3-fortran.org>
> Cc: Brad Richardson <everythingfunctional at protonmail.com>
> Subject: [EXTERNAL] Re: [J3] Proposals for new intrinsic procedures
>
> Thanks all for the suggestions, direction and background. I'll do scan
>
> (or whatever we end up calling it) as one paper, and the other IEEE
>
> procedures as one paper. If anybody has suggestions for the spelling of
>
> INCLUSIVE_SCAN and EXCLUSIVE_SCAN let me know. I'll definitely have it
>
> as a straw vote.
>
> Regards,
>
> Brad
>
> On Thu, 2023-01-05 at 19:35 +0000, Brad Richardson via J3 wrote:
>
>> Hi all,
>>
>> Would proposals for new intrinsic functions be acceptable to submit
>>
>> for
>>
>> the upcoming meeting? Specifically I've been asked to write up the
>>
>> papers for:
>>
>> * prefix sum (commonly known as scan, but of course that name's
>>
>> already
>>
>> taken), both inclusive and exclusive
>>
>> * All functions recommended by IEEE-754, most of which Fortran
>>
>> already
>>
>> has, but the whole list is reproduced below
>>
>> exp
>>
>> expm1
>>
>> exp2
>>
>> exp2m1
>>
>> exp10
>>
>> exp10m1
>>
>> log
>>
>> log2
>>
>> log10
>>
>> logp1
>>
>> log2p1
>>
>> log10p1
>>
>> hypot
>>
>> rSqrt
>>
>> compound
>>
>> rootn
>>
>> pown
>>
>> sin
>>
>> cos
>>
>> tan
>>
>> sinPi
>>
>> cosPi
>>
>> tanPi
>>
>> asin
>>
>> acos
>>
>> atan
>>
>> atan2
>>
>> sinh
>>
>> cosh
>>
>> tanh
>>
>> acosh
>>
>> atanh
>>
>> Some points of order questions also. Which subgroup is in charge of
>>
>> the
>>
>> intrinsic procedures so that I can coordinate with them? Would it be
>>
>> best to write a separate paper for each new procedure, put them all
>>
>> in
>>
>> a single paper, or some scheme for grouping certain subsets? And
>>
>> whilst
>>
>> we don't have final version of F2023 to draft the edits against,
>>
>> would
>>
>> it be worthwhile to go ahead and detail out what they will look like?
>>
>> Thanks in advance for any feedback.
>>
>> Regards,
>>
>> Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20230106/79ba8644/attachment-0001.htm>