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

Sat Dec 23 03:14:48 UTC 2023

Hi Tom,

In general, it is fine to move SIMPLE procedure references across non-SIMPLE procedure calls.

It is Not Fine to move *Anything*, even “a + b”, across a call to IEEE_SET_ROUNDING_MODE and a tiny handful of other special routines. “Anything” includes a reference to a simple procedure, of course.

Cheers,

-- 

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

From: Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov> 
Sent: Saturday, December 23, 2023 12:25 AM
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?

To be fair, I think Malcolm was closer to what I meant when I wrote my original question, but Brad is closer to what I was trying to get at.

Basically, I was wondering if it was possible to have a sequence of SIMPLE procedure calls in which reordering would result in a different answer.    If I’ve understood correctly this cannot happen with the co-arrays because as change team and the like are not permitted in SIMPLE procedures.   Likewise,  the calls to _change_ the rounding mode are not themselves SIMPLE.    Thus, if a compiler “understands” that it should not (under safe optimizations) move invocations of SIMPLE procedures across non-SIMPLE invocations we are in pretty good shape   Otherwise we would lose an important property of DO CONCURRENT.  Whew.

*	Tom

P.S. Yes – I recognized that any simple procedure involving FP arithmetic was also vulnerable, but wanted to leave that as my counterstroke.   But Malcolm beat me to it.

From: J3 <j3-bounces at mailman.j3-fortran.org <mailto:j3-bounces at mailman.j3-fortran.org> > on behalf of j3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> >
Reply-To: j3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> >
Date: Thursday, December 21, 2023 at 9:03 AM
To: j3 <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> >
Cc: Brad Richardson <everythingfunctional at protonmail.com <mailto:everythingfunctional at protonmail.com> >, Malcolm Cohen <malcolm at nag-j.co.jp <mailto: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. 

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/20231223/88a213ba/attachment.htm>