Palo Alto, California

August 6-7, 1998

* Math Libraries in Java3D, Henry Sowizral, Sun

* Proposed Java Matrix Classes, Cleve Moler, The MathWorks

* Java Numerics Issues, Joe Darcy and William Kahan, UC Berkeley

* Sun's recent proposal for extension of Java floating-point semantics

* Draft report of the Numerics Working Group

* Proposed matrix class

* Proposed complex class

* Behavior of elementary functions

* Status of other proposed class libraries

* The Scimark benchmark of NIST

* The basic positions in the draft report on the issues of complex, efficient classes, operator overloading, and multidimensional arrays were affirmed.

* The section of the draft report dealing with floating-point arithmetic will be substantially rewritten in light of Sun's recent proposal. The main points are as follows.

- Sun's recent proposal goes too far in relaxing floating-point semantics. A more modest change would have the effect of allowing efficient use of Intel processors while maintaining as much predictability as possible for numeric computations. The essence of this is

o JVMs are allowed to use 15-bit exponents in representing doubles on the stack. This implicitly allows extended double to be used on Intel processors, and results in nearly reproducible results, i.e., differences happen only rarely (in cases where double would overflow or underflow).

o A "strictfp" keyword for methods and classes can be used to force the original strict floating-point semantics of Java. The default would be the looser semantics described above. JVMs should have a global switch to override loose/strict specifications in the class file and force an entire computation to be strict. Users should have access to this switch. A widefp keyword is not necessary.

- Fused multiply-add instructions should be allowed as the default. (This is a byproduct of the extended double rule above.) The strictfp keyword implies that the fused multiply add cannot be used.

- Standard methods to sense, save, clear and raise all IEEE floating-point flags should be included in Java.

- Standard methods to get and set IEEE rounding modes should be included in Java.

- There should be a mechanism to allow compilers the freedom to rearrange computations based on the associative law. This should not be the default. There was less agreement as to how to signal use of such optimizations. One possibility is to have a keyword licenseAssociativity associated with methods.

- Some sentiment for a longdouble data type, as well as for an indigenous (long double if fast, else double) data type. It was agreed that these could be introduced using the same mechanisms as complex.

* Visual Numerics presented a proposal for a complex class. JGF members are urged to visit http://www.vni.com/corner/garage/grande and to voice their opinion on its design and functionality.

* The behavior of the elementary functions in Java was discussed. It was observed that current Java implementations of these functions do not produce reproducible results because JVMs implement them by calls to local C libraries. It was recommended that the fdlibm suite be translated to Java, and that this implementation of the elementary functions be mandated when strictfp is designated.

* Status of other class library efforts:

- IBM is working on a proposal for a multidimensional array class.

- Sun is working on a proposal for an interval arithmetic class.

- A suite of efficient Basic Linear Algebra Subroutines (BLAS) for Java should be constructed. These are meant for use by developers of linear algebra software and those for which performance is paramount. Only Level 2 and Level 3 BLAS are reasonable candidates for this effort. NAG and NIST will pursue this.

- The University of Houston is considering developing a proposal for an FFT class.

* NIST described its Scimark benchmark, a composite of scientific computing kernels, including FFTs, finite difference stencils, Monte Carlo computations and solution of sparse and dense linear systems, packaged as a Java applet. This will be released soon.

* The Working Group chairs will revise the draft report of the group and circulate it among JGF members by August 25. Comments will be solicited for approximately two weeks. A final revision will be ready for public distribution by September 15. A copy will be sent to javasoft-spec-comments@eng.sun.com.

* Working group members will review the proposed complex class and forward comments to the JGF.

* IBM will prepare a proposal for an array class and distribute it to JGF members.

* NIST will announce the initial release of the Scimark benchmark to JGF members and solicit comments on its usefulness.

* The Working Group chairs will prepare a presentation on the Working Group's report for the Java Grande Panel at SC'98.

Ron Boisvert (NIST)

John Brophy (Visual Numerics)

Dimitri Chiriaev (Sun)

Jerome Coonen

Joe Darcy (Berkeley)

David S. Dixon (Mantos Consulting)

Siamak Hassanzadeh (Sun)

Lennart Johnsson (Univ. Houston)

William Kahan (Berkeley)

Cleve Moler (The MathWorks)

Jose Moreira (IBM)

Roldan Pozo (NIST)

Kees van Reevwijk (Delft)

Henry Sowizral (Sun)

Anne Trefethen (NAG)