Re: P1788 Motion M0021.02 YES
> Subject: Re: P1788 Motion M0021.02 YES
> From: John Pryce <j.d.pryce@xxxxxxxxxxxx>
> Date: Tue, 7 Dec 2010 10:16:54 +0000
> To: stds-1788 <stds-1788@xxxxxxxxxxxxxxxxx>
>
> P1788
>
> If Motion 21.02 had said the features described are
> *required* I should certainly have voted NO. The
> position paper is unclear about this because the
> standardese words "shall", "should", "required" etc.
> hardly occur, and don't make the intent obvious.
>
> But Juergen & Marco's accompanying motion statement,
> below, make it clear these features are *recommended*:
John,
This too is cause to reject the motion.
If the intent is to put something as fundamental
as comparison relations under "should", they
have no portable utility at all.
Remember, the implementer's interpretation of
the word "shall" is "I NEED to do it" & the
word "should" is "I DON'T need to do it".
As such, if the comparisons themselves are not
under 'shall' they cannot be counted on to be
used in portable code. Indeed, they cannot even
be written into pseudo code in peer reviewed
papers as some reviewer will reject that paper
on the grounds that the code cannot be reliably
written.
Therefore, the list of comparisons, whatever
they are, should all appear under 'shall'.
> > Motion 21.2
> >
> > . . .
> >
>
> I think this is right. This implies they will appear
> in an Annex. Those who, like Nate, can see a use for
> them and maybe an opportunity to put them into hardware,
> will implement them. If the result looks appealing,
> people will say "me too", other implementations will
> appear and maybe the feature will become required in
> a future revision. If not, not.
>
> Therefore I vote YES. People who voted no, did you vote
> against even the _option_ of this feature?
>
> John Pryce
As you point out, the motion speaks of the 'state'
associated with comparisons in the same language as
it does of the comparisons themselves. To quote
from the introduction:
In [6] we have shown that the general overlapping
relation can be efficiently implemented in hardware.
4 bits are sufficient to encode the different states.
Together with an object oriented interface allowing
the direct access to the states (cases) this will
presumably lead to a better performance of
application programs.
The notion of some hardware operation that returned
a 'state' rather than true or false was thought to
be interesting in 1985. The idea was that, having
acquired the 'state' you now have all the information
needed to make any comparison you require.
But this is not how algorithms are written. One knows
in advance what relation is needed & all one needs to
know is whether that relation is true or false. The
burden of the creation of state on the chance that you
MIGHT want save the need to do another comparison turned
out to be a very poor tradeoff indeed.
So, not only would vote against a motion that considered
state under 'shall', I would vote against a motion that
suggested it under 'should'.
So, yes, I would vote against even the option of such a
thing.
However, if my interpretation is incorrect & you believe
the intent is to define a list comparisons under 'shall'
& NOT to define state at all (even under 'should') then
you may have my YES vote.
Even if we all agree that you, as editor, will write the
document in that way, you may have my YES vote.
But, until we come to that understanding, I think I will
still vote NO.
Yours,
Dan