Quoting David Noon to George White in a message dated 12/12

DN> On Monday, 95/12/11, George White wrote to David Noon about "Cube
DN> root" as follows:
DN> 
DN> GW> DN>took about 40% less time than using pow(). I think that pow() is
DN> GW> DN>implemented in the BCAF 3.1 run-time as exp(log())
without any further
DN> GW> DN>thought on Borland's part.
DN> GW> 
DN> GW> I've just looked, its coded in assembler in the run time library
DN> GW> source.
DN> 
DN> Hi George,
DN> 
DN> I just took a look at the source too. It is in assembler, but it
DN> uses 2**(y*LOG2(x)) in order to evaluate x**y; almost as inefficient
DN> as EXP(y*LN(x)). 

Dave, given that it has to be computed using instructions available to
the FPU, how would you code it?  AFAIK the method you describe makes the
best possible use of the FPU for this function.  The FPU has no general
exponentiation instruction (only one for raising 2 to a power) and the
only logarithms it does are to base 2.  If you know a more efficient
algorithm for the Intel FPU, I'd -love- to know about it, since I'm
using 2**(y*LOG2(x)) in an assembly language math unit I've started
writing for Virtual Pascal.  (so far power is the only thing done)

2**(y*LOG2(x)) is all done in a single call to a FPU procedure, and
errors from converting FPU temporary real numbers (80 bits) to C double
precision reals (64 bits) don't accumulate, only happening when the
result is returned.  Techniques are (or *should be*) used in the
procedure to attain an effective word length greater than 80 bits.

EXP(y*LN(x)) isn't just slower, it's more subject to errors.  The FPU
has no direct EXP or LN instruction.  There will be three calls to FPU
procedures (wasting time, of course): LN, then a multiplication, then
EXP.  Conversion errors occur at each return, and accumulate.  There are
inevitably errors in each procedure call as well.  

just my $.02 worth 

Patrick

___
 X KWQ/2 1.2i X I'm not young enough to know everything anymore...
--- Maximus/2 2.02