🚀 go-pugleaf

In article <AGLEW.89Oct27193246@chant.urbana.mcd.mot.com>, aglew@urbana.mcd.mot.com (Andy-Krazy-Glew) writes:
> And in another FP question, I notice that the IBM America (RT-2?) has
> a multiply-accumulate instruction that performs no intermediate
> rounding.  Ie. it is ROUND(A*B+C).  This is "more accurate" but does
> not necessarily produce the same answers as ROUND(ROUND(A*B)+C).
> I wonder what the numerical analysis mavens have to say about this:

Check
	Compiler Support for Floating-Point Computation
	Charles Farnum
	Software--Practice and Experience 18(7) 701-709 July 1988

Also check ANSI/IEEE Std 854-1987. 
A relevant part of that standard says:
	"Some languages place the results of intermediate calculations
	in destinations beyond the user's control.  Nonetheless, this
	standard defines the result of an operation in terms of that
	destination's precision as well as the operand's values."
It seems to me that one might be able to get away with saying that
	X := A*B+C
is a case where the intermediate result A*B is placed in a (notional)
double-extended destination; this would interpret X := A*B+C as
	X := round_to_double(			% there are
		double_extended_sum(		% three rounding steps
		    double_extended_product(	% in this expansion
			extend_double(A), extend_double(B)),
		    extend_double(C)))
Section 3.3 of IEEE Std 854 specifies only lower bounds on 'extended'
range and precision, so double-extended could be big enough for
double_extended_sum and double_extended_product to do no rounding in
this case.  Provided that double-extended was not otherwise provided
it seems to me that this implementation could conform to IEEE Std 854.

If, however, your program contains the statements

	begin double AB := A*B; X := AB+C end;

then this may *not* be translated using the multiply-accumulate
instruction, because the results are specified precisely by IEEE 854.