[J3] [BULK] Re: [EXTERNAL] Should all intrinsic functions be simple?
Brad Richardson
everythingfunctional at protonmail.com
Thu Dec 21 14:03:40 UTC 2023
> 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/20231221/b14042f0/attachment.htm>
More information about the J3
mailing list