Re: Some thoughts on Motion 19 (still under vote)
> Subject: Re: Some thoughts on Motion 19 (still under vote)
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: Fri, 17 Sep 2010 09:56:08 +0100
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> Arnold, P1788
>
> First:
> It has been pointed out that the Motion 19 position paper
> (M19 for short) contradicts M16.
> This seems to be true, and was an oversight.
> - I guess the 2nd clause of "proposed revised Conformance
> requirements" in 3.4 of M19 is not compatible with M16's
> requirement "a conforming implementation shall support at
> least one inf-sup type".
> - Does the group see any other incompatibilities?
>
> Chair, what to do?
> Must Dan and I withdraw the motion and resubmit after revision?
> Or can we make a "what we really meant was..." statement, and
> the group continues the vote?
> (I think in a face to face meeting that would be allowed.)
>
> . . .
>
> What do people think?
>
> John Pryce
It would be allowed.
Rather than withdraw motion 19, however, it might be
better for someone who feels strongly about this to
propose an amendment to the effect that at least one
explicit is required for an implementation to conform.
But I'm not so sure the distinctions between the
positions of motions 16 & 19 are all that bad for now.
Motion 16 sought to distinguish between 'supported'
& 'available'. Basically that there are first class
datatypes (supported) & second class or deprecated
datatypes (available). And that there should be at
least one inf-sup among the first class types.
That is, motion 16 is making the judgement as to the
worth of these types. It may be a correct judgement,
as Arnold believes, but it is there all the same.
It seems to me that in motion 19 you distinguished
interval datatypes by their capabilities. "Explicit"
when they could be easily well specified & "implicit"
when they could not. And you made this important
separation at level 1 & 2 without reference to their
level 3 & 4 representations.
It is this that I think is useful to us.
Yes, in making this separation you may have
inadvertently raised the mid-rads (currently implicit)
to a less deprecated status but, for the moment anyway,
I think that is OK.
It gives us (as a standards body) the ability to
continue to well characterize the explicits without
the conceptual difficulties involved in considering
all flavors of intervals out there.
It gives the mid-rad people breathing space within
which they can try to shore up the behavior of their
favorite mid-rad datatypes to something that is
acceptably reproducible & tight.
And it gives all of us the ability to make progress
on any part of the standard without the problems of
other parts getting in the way.
We are not done yet. Future motions will be needed
to make this standard whole. For the moment, I don't
believe we know enough to decide much further than
motion 19 goes.
If, as Arnold believes, it is impossible to specify
acceptable behavior among some subset of the implicits,
they can be further deprecated or eliminated altogether
in some future motion. When that is known to be the
right thing to do.
If the mid-rad crowd comes up with something innovative
& useful, then they deserve a more active status.
Perhaps not at the bit-for-bit level of the explicits.
But some status where the user would be assured of
results from one machine to the next. Sort of a
separate but equal I suppose. :-)
And, as you pointed out in your note John, merely
being conforming doesn't mean an implementation will
be commercially successful. Or even make much sense
as an implementation.
If Arnold is correct & implicits turn out to be
unredeemably bad for assured computing, then I agree
we should further deprecate them or eliminate them
altogether. Then the conformance standard should be
"at least one explicit".
But we don't know yet.
Give them their shot.
Oh, the text string thing DOES need to be solved but
let that be an issue for a future motion. We have
enough trouble with this one as it is. :-)
Dan