Re: More on trits & tetrits... (long) - compromises
On 2010-04-29 13:49:07 -0400, Ian McIntosh wrote:
> Catching an exception on overflow would let one know when it happened. In
> that sentence I was referring to earlier discussion about the semantics of
> operations on Overflow versus Infinity, where Overflow represents a finite
> value that has overflowed.
>
> The key issue is that 754 defines 0 x Infinity to be NaNQ, while
> (simplified a bit) 1788 wants [0, 0] x [anything, Infinity) to be [0, 0],
> which is the right answer for 0 x Overflow (where the value Overflow
> doesn't exist in 754). The general IA approach is that Infinity can only
> be approached not reached, so a bound of Infinity really means a finite
> upper bound. One difficulty is that if you use a 754 multiply you will get
> the wrong answer, so you must either not use 754, or prevent the error, or
> detect and fix it.
Yes, and I would add that whatever meaningful answer we would like for
[0, 0] x [anything, Infinity), the problem with the IEEE 754 multiply
would be there.
Now, hardware implementations could define a non-IEEE-754 multiply
operator (where 0 x infinity would yield 0) that would be used only
to implement interval arithmetic. Whether this is really useful
is practice (compared to the alternative way of trapping invalid
operations such as 0 x infinity), I don't know.
> If 754 had included Overflow and Underflow as special "values" (meaning
> sets of values), a 1788 implementation based on 754 would be simpler and
> faster. And if you had special 1788 hardware I think there would still
> be advantages. The main disadvantage would be incompatibility with 754,
I don't see this as a real disadvantage if both versions are provided
by the hardware.
> but 754 users could benefit from it too so maybe it might become
> part of a future 754-201x?
I don't know. IEEE 754 hasn't been designed to satisfy everyone, but
as a compromise while remaining simple enough. If this is brought for
the next revision of IEEE 754, important questions would be whether
such additional values would be useful in other contexts, whether
they could break existing code, whether they could introduce too
many inconsistencies (like the asymmetry between signed zeroes),
and so on.
> Catching exceptions on rare cases like underflow and overflow and
> replacing the result value with the smallest Subnormal and a special
> NaN pattern respectively representing Underflow and Overflow would
> be an efficient way to implement the semantics. Thanks.
For the multiplication, I think that only 0 x infinity needs to be
caught (thus invalid results, not even underflow and overflow), and
that the cases where one has a zero in an interval and an infinity
in the other one are sufficiently rare.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)