32bit vs. 64bit

[Michael D. Godfrey]

 >
 > On 14-Mar-2009, Jaroslav Hajek wrote:
 >
 > | In the good old days (though I'm probably too young to talk seriously
 > | about those) when Fortran and single precision ruled, error analysis
 > | was just more important for computations to actually work.
 >
 > Back in the good old days some of the fastest systems for numerical
 > computing (CDC 6x00, for example) had 60-bit words, and Fortran REAL
 > values were 60 bits wide.  So yeah, single precision ruled, but it
 > provided more than the 32 bits commonly used for single precision
 > today.  Similarly, Cray-1, 2, XMP, YMP, etc. systems had 64-bit
 > "single" precision (i.e., Fortran REAL).
 >
 > jwe
And, Sergei said:
 > Well, it depends on what you're doing.
 >
 > Let's have a look at this example :
 >
 > octave:2> cos(2 * pi / 4096)
 > ans =  9.9999882345170e-01
Right. The problem is not solved by the fact that the data only have, 
say, 2 digits
of accuracy.  Wrong answers are still wrong.  FFT's show the problem and
so do problems that imply matrix inversions such as regression, optimization
codes, etc. Inverting a sufficiently ill-conditioned matrix produces 
large errors
at any precision.  The ill-conditioning can appear "by accident"  regardless
of the precision of the data or the theoretical stability of the 
system.  In addition,
the "solution" of just using higher precision does little good.  The 
position taken
in Forsythe and Moler that computations should evaluate the condition of the
result seems safer.  However, they also make the point that it is not 
possible
to evaluate the condition of a result in the precision used to compute 
it.  There
are situations where it is likely better to compute in single precision 
and evaluate
the result in double precision rather than just computing in double 
precision and
"hoping for the best."  This is all clearly explained in Forsythe and Moler.

 > Yes, and as Sergei noted, x86_64 actually doesn't use guard bits,
 > because it supports quadruple precision (128-bit fp).
 >   
Is this really true?  This seems like a bad choice and the "excuse" of 
quad precision
is irrelevant.  How did Kahan allow this?  Does someone have a reference 
to the
x86_64 floating point specs?  (By the way, I was around when Kahan 
forced IBM,
at very large cost, to retrofit guard digits into the original 360 
systems.  It was fun
to watch IBM trying sneak out of having to do that.)

On the Matlab "exact" idea, I understand that they wanted binary dumped data
to be "exactly" transferable over all their supported platforms.  This 
led them to
only use the IEEE subset of the least capable system that they support 
and to exclude
some systems that did not support the IEEE subset that they require.  I 
would
be very surprised if Cleve had a say in this.

Finally, speaking as someone working in EE at a University I find it 
worrying
that many students appear to believe that data originate as vectors in 
Matlab (or
Octave) and that computers always produce "correct" answers for any inputs.
All of our (computer controlled) measurement instruments, which really are a
blessing in convenience and capability, and our "handy" programming systems
do wonderful things, but they also conceal what is really going on in 
the process
of acquiring and processing experimental data.  Just me complaining 
again... But,
I feel a little better for it. And, I am glad that my original message 
produced some
good responses.

Thanks,
Michael