(j3.2006) Four IEEE procedures ought to be impure
Tue Jul 29 00:46:59 EDT 2008
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
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
> 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
> 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
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.
More information about the J3