[J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?

[Clune, Thomas L. (GSFC-6101)]

I think the term “corresponding” is used in the standard for co-array things that are the same place in the program.   But “not corresponding” is probably not quite what you are looking for.


  *   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, December 22, 2023 at 10:07 AM
To: j3 <j3 at mailman.j3-fortran.org>
Cc: Jeff Hammond <jehammond at nvidia.com>, Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: Re: [J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.


Do we have language to describe “different places in a program”?  I’m not sure that’s going to work, either, since I can change the context for a single call site based upon how I get there.  It’s not a matter of place but the entire path take to get to a place that matters, isn’t it?

Can’t we just address the teams issue directly, and perhaps add a comment about IEEE rounding mode business?

Jeff

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Brad Richardson via J3 <j3 at mailman.j3-fortran.org>
Date: Thursday, 21. December 2023 at 16.03
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Brad Richardson <everythingfunctional at protonmail.com>, Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: Re: [J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?
External email: Use caution opening links or attachments

Tom:
> SIMPLE procedure that plays games with TEAMS

Pretty hard to do since image control statements are forbidden in SIMPLE, so one SIMPLE procedure execution is thereby all in the same segment as the calling statement.

I believe Tom's point was that SIMPLE procedures can give different answers when executed in a different team, not that a SIMPLE procedure could change teams. At any rate, we've clearly established that SIMPLE procedures can give different answers when executed in different places in a program.


Tom:
>the trig functions are not SIMPLE…?
Brad:
> I don't know that I want to go that far

Tom did not go far enough. All floating-point arithmetic depends on the rounding mode (that is kind-of the whole point of having a rounding mode!).

Here is the example you should be thinking of, not SIN or COS or any other intrinsic.

SIMPLE REAL FUNCTION ADD(X,Y)
REAL,INTENT(IN) :: X,Y
ADD = X + Y
END FUNCTION

Nearly always gives different answers for sufficiently different rounding modes.

I generally consider floating point arithmetic to be a bit "fuzzy" anyways, but yeah, point taken, even intrinsic operations are not independent of program state.


Brad:
> the Fortran definitions of PURE and SIMPLE aren't quite what people coming from other backgrounds might intuit

That’s certainly true for PURE, though my recollection is that there is not universal and complete agreement on all the fine details of “pure”.

But surely no-one should be confused by SIMPLE, as we did not hijack an existing jargon term, we only hijacked an ordinary English word. No-one will know what it means without reading our definition. (Well, it might be an obscure jargon term I’ve forgotten, or never heard before, but it is surely not widely understood if so.)

Well, given that I was confused at first, and that the standard says (effectively) "SIMPLE procedures are PURE, plus some additional constraints" and that those additional constraints seem to be implying independence from everything but their arguments, one could certainly argue that confusion is not unlikely, especially when looked at as a quick reference.


Damian:
> the standard doesn't guarantee that simple procedures are deterministic

Actually I think they are usually deterministic. That word does not mean “does not depend on the rounding mode”. The ones that are not deterministic are ones that evaluate stuff in parallel and combine them in an unpredictable order, like a multi-threaded SUM might do.

I really do not see any problem here that would be helped by a NOTE. The vast unwashed masses that don’t understand floating-point, or don’t understand environments, are still going to be confused whatever we write.

Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.


So, we've established that no SIMPLE procedures (effectively) can be assumed independent of their environment. My question then is, what did we go to the trouble of adding it to the language for? Was it really just to promise to the compiler that it can directly associate the variable in an assignment with the result of a function call? I.e. `x = some_func()` Because that's not even always true. I.e. `x = something_else(x)`, you'll have to do a copy in if you want to do that. Or `x = something_finalizable()`, you'll still have to run a final subroutine, so still need a temporary. So, what benefit do I get from using the SIMPLE keyword over the PURE keyword?

Regards,
Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20231222/3b49c4b9/attachment-0001.htm>