Re: A proposal for the next motion
> Date: Mon, 18 May 2009 11:33:00 +0200
> From: Vincent Lefevre <vincent@xxxxxxxxxx>
> To: STDS-1788@xxxxxxxxxxxxxxxxx
> Subject: Re: A proposal for the next motion
>
> On 2009-05-17 22:34:39 -0400, Nate Hayes wrote:
> > Vincent Lefevre wrote:
> > > There are (global) flags in IEEE 754-2008. Their scope is
> > > language-defined.
> >
> > . . .
>
> > In this case, like I mention earlier, I believe "local flag" or
> > "attribute" (which could be implemented as dual op-codes, for
> > example) is best option, i.e., the user must explicitly define the
> > behavior when invoking the function. This way, the user can choose
> >
> > sqrt([-4,-1]) = NaI or sqrt([-4,-1]) = {empty}
> >
> > without needing to remember to check a global status flag after the
> > fact (or without needing to change a global control flag before,
> > either).
>
> That's a possibility, but I'd rather prefer the following one:
>
> sqrt([-4,-1]) = (empty,invalid)
> sqrt([-1,4]) = ([0,2],invalid)
>
> i.e. an "invalid" flag is attached to the returned interval.
> With this choice, the "invalid" flag is set if and only if
> you would get NaI with your choice. This just provides more
> information.
>
> Also, I said that instead of attaching the "invalid" flag to
> the result, one could have a "status flag" with the meaning of
> IEEE 754-2008. The advantage is that if the program produces
> lots of output, the user does not need to check each result:
> he can simply test the flag.
>
> > >>>> . . .
>
> --
> Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
Folks,
Vincent is correct that we tried to limit the scope of things
like flags & modes in 754-2008. He is also correct that we
were able to do a better job with modes --> attributes due to
the precedent of Itanium. I think we were less successful
with flags & the best we could compromise on is language that
is a bit vague on the scope.
But I would also like to point out that Vincent's example of
tagging a result with its exception history (e.g.: sqrt([-4,-1])
as {empty,invalid}) has an early precedent & might turn out to
be better for us than NaI's.
Years ago the lanugage Forth had to resolve the difficulty of
apparently global flag & mode state in a language that has no
global state at all. Their solution was to tag each result with
another 10 bits (flags & modes) that was the merge of the flag
& mode state of its operands together with any new flags set by
the operation. Thus each result had its own context which was
naturally interpreted as the exception history of everything
that led up to that result.
Not a bad resolution, IMHO.
For us, such a thing would not require us to choose between NaI
& empty for a result. When a result is [empty] due to some
error it could be returned as {[empty],error}. As the rule
would be that errors are 'OR'ed with errors they would persist
like NaIs & be easily testable even if the final result is
something normal looking like {[0,1],error}.
Also, we need not be bound by 754's selection of errors. They
make a good starting place but we could add things idiosyncratic
to intervals (or modals, for that matter) that aid in the better
interpretation of interval results.
Let me give two simple examples. (1) sqrt([-4,-1]) could be
{[empty],domain-error} rather than overload invalid with that
meaning. The test for NaI is then isDomainError(xx) (or maybe
isNaI(xx) which could be isDomainError() 'OR'ed with anything
else that is considered to contribute to NaI's) & would persist
throughout any calculation. (2) {[0,-100],modal} +
{[0,101],noException} could be {[0,1],modal} as a hint that an
unusually narrow standard result is due to a modal intermediate
rather than narrow operands.
In the end I'm not sure I recommend this approach but it must be
admitted that it has its merits.
Just my 0.0148214021 Euros worth. :-)
Enjoy,
Dan