🚀 go-pugleaf

In article <9106072346.AA08023@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
 >          I don't believe interval arithmetic is used enough to justify
 > any hardware support.
Well, IBM thought it important enough to provide support in some models (43xx).
Acrith is the keyword.

 >                        Providing quad precision (much more useful in
 > my opinion) would also provide some support of interval arithmetic.
Nope, it would not provide support at all.  You can not do interval arithmetic
with any extended precision without extensive software support.  On the other
hand, proper rounding modes are sufficient.

 >                                                                      In
 > any case I believe your estimate of 3x slower than straight floating
 > point is unrealistic.
How come unrealistic?  Example, interval add a to b giving c:
	set round to - inf;
	c.low = a.low + b.low;
	set round to + inf;
	c.upp = a.upp + b.upp;
why would this be more than 3x slower than straight floating point?  Now
consider the same in software (considering reasonable arithmetic):
	c.low = a.low + b.low;
	if(a.low < b.low) {
		if(c.low - b.low > a.low) c.low = nextbefore(c.low);
	} else {
		if(c.low - a.low > b.low) c.low = nextbefore(c.low);
	}
	c.upp = a.upp + b.upp;
	if(a.upp < b.upp) {
		if(c.upp - b.upp < a.upp) c.upp = nextafter(c.upp);
	} else {
		if(c.upp - a.upp < b.upp) c.upp = nextafter(c.upp);
	}
and consider the additional effort to implement nextbefore and nextafter.
And do not try this on a hex machine; it will not work.
So how would this benefit from some form of extended precision arithmetic?

 > The rounding modes may appear cheap but they have a large hidden cost.
 > Every intrinsic function subroutine for example must worry about handling
 > all rounding modes.
Only if they are expecting overflow or underflow in some particular situations.
In that case they better worry anyhow to prevent uncalled for overflows and
underflows.  The design of intrisic functions with the correct rounding modes
is of course a different art.  I think the Karlsruhe people have gone a long
way along this path.

 >        According to "Computer Architecture a Quantitative Approach" (Hennessy
 > and Patterson, p.A-53, p. E-2) none of the MIPS R3010, Weitek 3364, TI 8847,
 > Intel i860, Sparc or Motorola M88000 architectures implement IEEE double ex-
 > tended.
...
 > My objection to the IEEE double extended format is that it should be 128 bits
 > wide and called quad precision.
In that case none of the above machines would have implemented quad precision.
However, Motorola and Intel provide double extended, and the HP-PA architecture
provides quad.  But on the current implementations quad on HP-PA is in
software, so what is the advantage?
--
dik t. winter, cwi, amsterdam, nederland
dik@cwi.nl