Re: A proposal for the next motion
On 2009-05-18 10:59:01 -0400, Nate Hayes wrote:
> It does not matter if language defines the scope, since it requires
> user to do two things:
>
> 1. Execute the desired operation
> 2. Remember to check a status-flag, after the fact
Note that (2) can be done only at the end (if the user wants
to, as in many applications, the flag can safely be ignored);
the exception could also be handled in an alternative way (see
IEEE 754-2008, Section 8), in which case the handler could set
the result to NaI, and this is exactly what you want.
> This is the situation I don't believe is acceptable. It provides no
> mechanism or provision to generate a propagating NaI result, i.e.,
The flag is sticky, so that the status is propagated. So, what
do you mean?
> > 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.
>
> It is interesting idea, but I don't see it is realistic or useful...
> it is not compatible with existing IEEE 754 data formats,
Any form of interval is not compatible with IEEE 754, since IEEE 754
deals with numbers, not intervals.
> since it requires extra storage.
This may be a problem or not, depending on the application.
> It also does not provide a mechanism for propagating NaI, like
> mentioned above.
Wrong. Of course, the invalid flag [meaning "possibly invalid"]
must be propagated.
> Also, it does not generalize to interval functions which may be
> invalid over parts of the domain, but then may be valid over other
> disconnected intervals.
What do you mean?
> For example, what then is the result of
>
> tan(-100,100) = ?????
Interval = R, invalid flag set.
> > 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.
>
> What I mean is: c-set interpretation (which you advocate as default
> behavior), transforms, by implication, 1/0 into +oo:
>
> 1/[0,3] = [1/3,1/0] = [1/3,1/0=+oo).
No, 1/0 is not +oo. You would need an *unsigned* infinity.
> >>> 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.
>
> All 754 formats require subnormals!
1788 should not assume that the underlying arithmetic is necessarily
IEEE 754. Interval arithmetic makes sense with other arithmetics
(possibly more powerful, e.g. with an unbounded exponent range).
--
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)