(j3.2006) Four IEEE procedures ought to be impure

[Malcolm Cohen]

Van Snyder wrote:
> On Mon, 2008-07-28 at 14:11 -0500, Bill Long wrote:
>   
>> Van Snyder wrote:
>>     
>>> The four IEEE procedures that aren't allowed in DO CONCURRENT
>>> constructs, viz. IEEE_GET_FLAG, IEEE_GET_HALTING_MODE, IEEE_SET_FLAG and
>>> IEEE_SET_HALTING_MODE,
Why do you say this?  C829 lists three procedures, not four.
> Yeah, I thought about this after I sent the suggestion.  We are
> schizophrenic about this.  In CONCURRENT, we don't allow these guys
> because they're not really pure (even though we say they are),
IEEE_SET_FLAG is nearly as pure as addition, multiplication, subtraction 
and division: in fact it's possible to perform the "set to .TRUE." part 
via addition et al.

One might plausibly argue that IEEE arithmetic itself is not pure, but 
although that is technically true as defined by 754, adhering to that 
view isn't a constructive response to the question of providing pure 
(viz safe for parallelism) procedures.

> It seems a little odd that we can't invoke these procedures directly
> within a CONCURRENT construct, but we can get them invoked by putting
> them into a pure procedure.  This wouldn't allow setting the flags in
> any meaningful way within an iteration but outside of the pure
> procedure, but it would allow inquiring them, so why do we prohibit
> IEEE_GET_FLAG at all?
Because it is IEEE_GET_FLAG that is the main problem.  It's not a 
problem calling it in a PURE procedure because the flags get set to 
clear on entry; it is a problem in DO CONCURRENT because it would enable 
cross-iteration communication.
>   Same for IEEE_GET_HALTING_MODE.
>
> Oddly, IEEE_SET_FLAG is not proscribed by C828 or C829.
>   
That seems reasonable to me.  If we wanted to prevent all information 
leakage (from the construct), a non-constraint prohibition against 
setting flags quiet would be adequate; maybe that is a good idea.  (Or a 
constraint against calling IEEE_SET_FLAG with FLAG_VALUE being anything 
other than an initialization expression whose value is .TRUE., maybe 
that's going overboard though.)  As noted above, IEEE_SET_FLAG by itself 
does not enable cross-iteration communication.
> This begs the question "what values do IEEE flags (e.g. overflow) have
> when a CONCURRENT construct terminates?"
Adequately answered by the current text.
>   Should IEEE flags be handled
> as they are for procedures (14.3p3-5),
Obviously not, since there is no text that says that.
>  or should we just say that any
> flag that is signaling before the construct starts, or that signals
> during any iteration, is signaling at the end?
>   
That's what the text already says.  Why do you think a DO CONCURRENT 
isn't an executable construct?  You want us to say "If a flag is 
signalling at the beginning of an assignment statement, it is signalling 
at the end of the assignment statement" as well?  What's your problem 
with the existing text "Once signaling within a procedure, it remains 
signaling unless set quiet by an invocation of the subroutine 
IEEE_SET_FLAG or the subroutine IEEE_SET_STATUS".

Or maybe you are suggesting an alternative to the current situation: 
that we should set flags quiet at the beginning of each iteration of a 
DO CONCURRENT and merge the end-of-iteration values together at the end 
of the execution of the construct?  That would allow us to use 
IEEE_GET_FLAG within the construct with no problems, and would only have 
any overhead if a loop actually contained a reference to IEEE_GET_FLAG.  
I don't find this idea very appealing, not because of the overhead, but 
because it's inconsistent with other constructs.  And if people want to 
do IEEE flag testing they can already encapsulate the loop body in a 
procedure, so it's not like there is no way for them to do their IEEE 
flaggy stuff.
> Digging a little deeper, I notice that IEEE_*_ROUNDING_MODE and
> IEEE_*_UNDERFLOW_MODE are impure.  So one can't use pure procedures to
> implement interval arithmetic.  After we abandoned incorporating
> interval arithmetic as an intrinsic feature of F2003, one of our
> mandates was to adjust things so that users could roll their own
> efficiently.
And we didn't even make a serious attempt to fulfill that mandate 
(IMNSHO).  But the water has already gone under that bridge, and anyway 
it burnt down.

Cheers,
-- 
....................................Malcolm Cohen.