🚀 go-pugleaf

In article <81@radix> jimv@radix.UUCP (Jim Valerio) writes:
 > I feel compelled to respond, seeing that I'm an advocate of systems
 > supporting extended precision.  I'll first give an example how extended
 > precision helps, and then try to answer John's question of how well keeping
 > intermediate results in extended precision works.
I feel compelled also, I like also extended precision, but I think it should
be an option for the programmer.
 > 
 > Here's what the 4.3bsd libm suggests as an algorithm to get around the
 > overflow and underflow problem when extended precision is not available.
 > 
 > 		x = |x|
 > 		y = |y|
 > 		swap x,y if y>x
 > 		if (x==0) return(0);
 > 		if (y==0) return(x);
 > 		exp = logb(x);
 > 		x = scalb(x,-exp);
 > 		y = scalb(y,-exp);
 > 		return scalb(sqrt(x*x+y*y),exp);
 > 
 > However, the last line suffers from an undesirably large accumulated roundoff

And this is incorrect.  The last line does suffer some roundoff, but certainly
not large; less than two bits precision loss with a good implementation of the
sqrt and reliable floating point multiplication and addition (all other
operations are exact).

 > error.  So here's how the 4.3bsd libm actually implements hypot(x,y):

This is not entirely true.  The implementation above is the one used for
the Vax, the implementation that followed is for the IEEE machines.  That
other implementation has at most one bit loss of precision.
 > 

So indeed, extended precision and extended exponent range do help, but
not always.  Sometimes you want to have exact control over the precision
in which expressions are evaluated, so it must be left as an option.
Or more correct, there ought to be an option to turn off calculations in
extended precision.  On the other hand doing operations in extended
precision is only a valid option if it has no great penalty in preformance
(like K&R C).
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax