Subject: Re: Java Grande transcendental functions

From: Ronald F Boisvert <[email-masked]>
Date: Tue, 24 Nov 1998 10:45:13 -0500 (EST)

Dear Geoff,

Thanks for your comments on elementary functions in Java.  I am taking
the opportunity to forward this to the Java Grande Forum mailing list.
Please contact Geoffrey Fox ([email-masked]) if you would like to be
added to that mailing list.

Please see my comments below ...

> From [email-masked]  Tue Nov 24 01:29:23 1998
> Return-Path: <[email-masked]>
> Date: Tue, 24 Nov 1998 17:30:58 +1100
> From: Geoff Keating <[email-masked]>
> To: [email-masked]
> Subject: Java Grande transcendental functions
> Content-Length: 2104
> 
> 
> I was given your address by Geoffrey Fox, as the person to whom
> comments like this should be sent.
> 
> 
> I note that in the Numerics Working Group recommendations for Java
> Grande there is a small section on the transcendental functions.
> 
> I am in agreement with the section until the last paragraph, which
> reads in part
> 
> "As a compromise, we propose that fdlibm be translated to Java and
> ... be mandated when Java's strict semantics are being enforced. ..."
> 
> It is my belief that this is likely to lead to both slower and less
> accurate results than if precise rounding was required.  The problem
> with speed is that this would effectively mandate not only the results
> of the function, but the implementation required (as it would be very
> difficult to replicate fdlibm's exact pattern of errors in any other
> way), thus preventing use of, for instance, hardware implementations
> of the transcendental functions.

The rationale behind the recommendation to implement fdlibm in Java is
not that fdlibm is the fastest or most accurate.  It is simply portable
and reliable.  It is also how the elementary functions are defined for
Java already.

When Java is running in "strict" mode --- currently the only option ---
there is a promise of exact reproducibility of results when a given
class file is run on different Java platforms.  This is currently not
the case in practice.  The only way to provide this level of portability
is to develop standardized class files for the elementary functions which
would be required to be used on all Java platforms.  We are not absolutely
tied to fdlibm.  Any common implementation would do, although we would
certainly object if it were unnecessarily inaccurate and slow.  fdlibm is
fairly well respected, and has known properties.

We admit that the above solution is guaranteed to produce slower than
optimal results on any given platform.  We also expect it to be rarely
used in practice however.  The recommendation of the Forum is that the
default mode of operation of Java be less strict, which would allow
faster operation on most processors.  Use of vendor-specific implementations
of the elementary functions would be allowed under these circumstances,
provided that they produced results at least as accurate as the Java
implementations.

> fdlibm is also less accurate than most vendor libraries (as you would
> expect, otherwise vendors would just use fdlibm).  My testing
> indicated that its accuracy bounds on the exp() function were about
> 0.7 ulp.  I have a Java implementation of an exp() function that has
> accuracy bounds of about 0.503 ulp and is actually faster than the
> fdlibm version when implemented in assembler, on a typical RISC
> machine.

This is very interesting.  Would it be possible to provide this code
(or a link to it) via the JavaNumerics Web page so that others could
evaluate it?  (http://math.nist.gov/javanumerics/)

> Would it help if I improved the routine to be exactly 0.5 ulp (that
> is, precise rounding), as an example of how this is done?  The
> reference here is
> 
> P. W. Markstein, Computation of Elementary Functions on the IBM
> RISC System/6000 Processor, IBM J. Res. Develop., 34(1), 1990,
> pp. 111-119.
> 
> Although the author does not say it, the technique he uses can also be
> applied when the elementary function is being computed by hardware to
> higher-than-double precision as occurs in the Intel x86 processors.
> 
> The author says that the additional cost in time was around 20% for
> perfect rounding on the RS6000 processors he was using.  Since
> 'strict' mode will be about 50% slower for all other operations on
> some processors, this sounds like a bargin.
> 
> -- 
> Geoffrey Keating <[email-masked]>

Thanks for your comments.  I hope that you can continue to participate
in the discussions of the working group.

Best wishes,

Ron Boisvert
------------------------------------------+---------------------------
Building 820, Room 365                    | Voice +1-301-975-3812
National Institute of Standards and Tech. | Fax +1-301-990-4127
Gaithersburg, MD 20899 USA                |  Email [email-masked]
------------------------------------------+---------------------------
        URL  http://math.nist.gov/mcsd/Staff/RBoisvert/
----------------------------------------------------------------------

---

From: Geoff Keating <[email-masked]>
Date: Wed, 25 Nov 1998 13:53:06 +1100

> Date: Tue, 24 Nov 1998 10:45:13 -0500 (EST)
> From: Ronald F Boisvert <[email-masked]>
> Cc: [email-masked]

> evaluate it?  (http://math.nist.gov/javanumerics/)

I have put a applet wrapper on it and placed it under
<http://www.ozemail.com.au/~geoffk/exp_java/math_exp_applet.html>.

It won't work properly under Netscape, at least not version 4.05,
because it requires a bit of java 1.1, but it does run under Sun's
appletviewer.  I have provided source.