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

Fri Jan 6 17:32:17 UTC 2023

Brad,

I just meant you should not do a straw vote in the paper.  Just choose a sensible name, and define what it means.

Not seeing your concern about `co_scan`.   Lots and lots of useful things could be done with co_scan() IMO.

  *   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: Friday, January 6, 2023 at 12:27 PM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional at protonmail.com>
Subject: Re: [J3] [EXTERNAL] Re: Proposals for new intrinsic procedures

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<https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FPrefix_sum&data=05%7C01%7Cthomas.l.clune%40nasa.gov%7Cec389a2b11f04b2f13cc08daf00b5007%7C7005d45845be48ae8140d43da96dd17b%7C0%7C0%7C638086228627831836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EgIcNqjmX1d9DM01Vx%2BaN4lCLRCk2%2B%2FyrbRKPca7hQA%3D&reserved=0>) 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/14f69823/attachment-0001.htm>