Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: float/float = integer, remainder
Message-ID: <12248@mentor.cc.purdue.edu>
Date: 13 May 91 09:01:59 GMT
References: <9105130317.AA09926@ucbvax.Berkeley.EDU>
Sender: news@mentor.cc.purdue.edu
Lines: 37

In article <9105130317.AA09926@ucbvax.Berkeley.EDU>, jbs@WATSON.IBM.COM writes:
> 
>           Herman Rubin states:
>                                               I have already pointed out
> that every trigonometic and exponential routine does, in some way,
> float/float -> integer, remainder.  The integer is also used.
						     ^^^^
>           1.  As I have already pointed out, the actual computation being
> done is float/real -> integer, remainder (since pi and ln(2) are not ma-
> chine numbers).  A proposed float/float -> integer, remainder instruc-
> tion (assuming it ran at the same speed as floating divide, actually it
> would probably be slower) would not benefit the trigonometric or
> exponential routines on any architecture I am familiar with

Divide has been one of the stumbling blocks of computing since the
first speedups of multiplication.  You are right about the accuracy
part, and certainly for accurate computation, corrections would have
to be made.  It might run slightly slower than floating divide, but
not much unless the divide is done by multiplication, which it might
very well be.  Even then, some decent hardware support is called for.

I believe that the quote from me was taken from an article in which
I pointed out that communication between floating and integer registers
was important.  I have underlined the key word here; however things are
done, it is still necessary to get that integer to the integer unit,
and several steps, going trough memory, hardly seems to be the way.

>           2.  In any case it is not true that "every" exponential routine
> does this computation.  The scalar short precision exp routine in IBM's
> vs fortran library does not do this computation in any way.

I fail to see how one would compute exp(pi^3) even to short precision
without doing some computation like (pi^3)/ln2.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)