🚀 go-pugleaf

In article <7806@june.cs.washington.edu> rik@june.cs.washington.edu (Rik Littlefield) writes:
%In article <97749@sun.Eng.Sun.COM>, khb@fatcity.Sun.COM (Keith Bierman Sun Tactical Engineering) writes:

%<  Tom Lahey's fortran for the pc did this [kept 80-bit vars on the 80x87
%<  stack during loop execution]. Example:
  
%<  	sum = 0
%<  	do i = 1, n
%<  	   sum = x(i)*y(i)
%<  	end do
%<  
%<  produces the same answer when sum is dp or sp (x,y, sp..chosen to make
%<  this interesting).
%<  ........
%<  Tom's compiler worked it well enough that some customer's complained.
%<  So there is a compiler option that forces gratuitous stores to memory
%<  to force the conversion to 32-bits.
%<  
%<  Of course, this caused the results to be less accurate _AND_ slower.
%<  there is no accounting for taste.
%   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^              
%
%Perhaps these customers wanted to compare their results against other
%compilers/machines.  Maybe I'm just pessimistic, but when a new compiler
%produces answers that are much different from what I'm used to, "increased
%accuracy" is just about the *last* possibility that comes to mind.

Another reason involves portable numerical codes.
Consider a routine such as MCHEPS (?) from LINPACK
I think. It experimentally determines machine precision with a loop
which is roughly:
	COUNT = 1
	EPS = 1.0
	WHILE (EPS+1.0 > 1.0) 
		COUNT = COUNT + 1
		EPS = EPS / 2
After execution COUNT will be some number.

Since such a number will influence error estimates it would 
be nice if it reflected the precision of EPS in memory.

Strikes me that this represent a use of "volatile" and it
doesn't even invole exception handlers, device drivers or 
parallel processing.

David Callahan 	  Tera Computer Co. Seattle WA.