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.
>
> My understanding is IEEE 754-2008 attempts to stop speaking of global
> flags and instead speak of "attributes". For example, a conforming
> application could provide four op-codes for addition, one each with a
> different hard-wired rounding mode. This is not unlike the examples in
> Ulrich's letters to the IEEE.
I was not speaking of "attributes" (called "modes" in the old
IEEE 754-1985 standard), but what IEEE 754-2008 calls "flags"
or "status flags", e.g. in 7.1:
7.1 Overview: exceptions and flags
What's important is that flags are not attached to each result
but have some "global" form (I'm not sure of the right word to
mean that something is not attached to the result and affects
the environment). Then, what "global" really means, i.e. what
the scope is, depends on the implementation (this is typically
defined by the language).
> It is a more modern concept, i.e., "attribute" (I think I also heard
> Michel refer to this idea as "local flag"). The main idea is there
> is nothing that requires it to be global, like the rounding-mode
> control flags on current x87 FPUs, for example (which can flush the
> pipeline and give processor stalls when you change them).
This may be true for attributes, but AFAIK, not for the flags.
Also, concerning these rounding modes, that's an *implementation*
choice. In particular, IEEE 754 (including the 1985 version) has
nothing against rounding attributes (modes) implemented statically.
And some processors (e.g. ARM FPA, Itanium) implemented static
rounding attributes before the 2008 version came out.
> 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.
> >>>> If a counter-example really does exist, the two opcode solution
> >>>> mentioned above would be better idea, I think.
> >>>
> >>> It is not difficult to find counter-examples: the division (e.g.
> >>> 1/x), tan, arcsin...
> >>
> >> If "eps" is smallest machine number, then
> >>
> >> 1/([0,3]&[eps,+oo)) = 1/[eps,3] = [1/3,+oo)
> >
> > Your reasoning is incorrect. You cannot transform 1/eps into +oo (this
> > can work with some arithmetics, but not with all of them)!
>
> You also cannot transform 1/0 into +oo in all arithmetics, either!
I don't see what you mean: 1/0 is not defined, so is not transformed
into +oo. The IA implementation must take care of these particular
inputs.
> > Also, 1788 should make the underlying arithmetic transparent. I mean,
> > the user should not wonder what the smallest machine number is, for
> > instance.
>
> In IEEE 754, user does not need to know what smallest machine number
> is, but can be guaranteed 1/eps=+oo is always true.
This is not true for all arithmetics, in particular if subnormals
are not supported.
Also your expression will no longer be correct if you extend the
range (because eps depends on the range), and that's really annoying
and a potential source of bugs.
> > Yes, you're right for arcsin, but function tan would still be
> > problematic (and other possible functions not defined in 1788 but
> > seen as confirming just like what IEEE 754 allows).
>
> Tan is only function I can think of that would be likely to need
> special handling in this case.
You can add gamma functions (that are defined in the C standard,
and which users may want to be used as conforming functions),
and probably some special functions that are useful in particular
applications.
--
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)