Re: Standard Library Interest?

["Robert I. Eachus" <rieachus@comcast.net>]

Marin David Condic wrote:
> It always has been and always will be a "Political Problem". We've known 
> for aeons how to make a square root routine. Getting one that could be 
> accepted as "Standard" was a political problem. Just because its 
> "political" doesn't make it any less a "problem", so we need to find the 
> "political" will to do it. From there, the technology is relatively simple.

I don't want to harp on this, but WHO has known how to make a square 
root routine for aeons?  In the early sixties it was vital to NASA to do 
  square roots fast and accurately for the Apollo project.  I worked on 
this, and the eventual result was to modify four IBM 7094s to include a 
36-bit to 36-bit integer square-root function.  I won't go into a long 
discussion of WHY a 36-bit to 36-bit square-root with the implicit 
binary point to the right of the most significant digit was what was 
needed.  Just the thought of explaining to ONE more person why that was 
what was needed, and that it was a very simple modification of the IBM 
7094 to add it makes me want to scream.

In the mid-eighties when I was at Stratus, I showed the same thing to 
the hardware engineers responsible for the math co-processor software in 
the Stratus 200 and 600 series.  They agreed it would significantly 
improve the speed of their square root routines, but AFAIK, it was never 
implemented.  (This was when we were about to introduce the 2000 series 
which used Motorola 68881 math co-processors.)  Later, I implemented 
this square-root method in software for Sun SPARCs, since it was so much 
faster than Sun's math routines for most SPARC chips.  (Most UltraSPARC 
chips now seem to do the square-root correctly.)

So yes, I know how to use the Newton-Rhapson method to find square 
roots, and I also know how to implement a square-root in microcode so 
that it is faster than the hardware divide.  But the idea that this was 
well or widely known in 1983 is totally false.  There were CPUs in the 
nineties that still did it wrong.  (Of course, in the nineties Intel 
managed to get divide wrong as well.  Sigh!)  Most implementations of 
sine and cosine were pretty good, but other trig functions and all 
inverses were spotty.  Logs again were spotty both natural and common 
logs, and most implementations of exp were a horror.  Brian Wichmann did 
a lot of work on that, including finding cases where many compilers 
computed X**4 wrong, even when X was integer and the result was 
therefore exact.  (The IBM 360 series and follow-ons were infamous for 
printing the sum of 2.0 and 2.0 as 3.9999999999999...  But that was 
actually a problem in the Fortran print routines, not in the internal 
representation.)

-- 
                                        Robert I. Eachus

"Quality is the Buddha. Quality is scientific reality. Quality is the 
goal of Art. It remains to work these concepts into a practical, 
down-to-earth context, and for this there is nothing more practical or 
down-to-earth than what I have been talking about all along...the repair 
of an old motorcycle."  -- from Zen and the Art of Motorcycle 
Maintenance by Robert Pirsig