The working group reviewed the status of all ongoing projects and planned future work. Here we summarize the results of these discussions. For further information, see: Numerics Working Group homepage, and Java Grande Forum homepage.

1. Determine how the Java Grande Forum could be an official participant in the Java Community Process. (Boisvert, Lindholm)
2. Notify the working group by email of the status of the fastfp JSR. Solicit participation in a possible experts group. (Boisvert)
3. Decide whether to continue fastfp in the JCP 1.0 or JCP 2.0. (Moreira, Snir)
4. Incorporate minor changes into the fastfp JSR as requested by Sun and resubmit. (Moreira, Snir)
5. Decide whether to continue the multidimensional array API with the JCP 1.0 or to jump to 2.0. (Moreira, Pozo)
6. Modify the multidimensional array API JSR to accommodate the requests of Sun and resubmit. (Moreira, Pozo)
7. Finalize draft of the multidimensional array syntax JSR and circulate in the Java Grande Forum for comments. (Pozo and Moreira)
8. Complete development of draft complex JSR and submit to Java Grande for further review. (Darcy, Philippsen, Hare)
9. Complete preparation of fdlibm in Java for inclusion into java.lang.StrictMath. (Lindholm, Brophy)
10. Add "sanity checks" on results to Scimark. (Pozo)

Java 1.3 has been shipped. A Java Specification Request (JSR) describing the changes proposed for Java 2 Standard Edition (J2SE) version 1.4 has already been submitted. Language and VM changes must be included in one of these umbrella JSRs in order to be deployed. (JSRs for particular language changes can be done asynchronously with this, but ultimately they must be folded into an umbrella JSR to actually be included in a particular release.) It is unlikely that any of the language and VM changes that we are currently working on will be ready in time for 1.4, which is targeted for release in 2001. Sun is working on a 12-18 month revision cycle.

A new version (2.0) of the Sun Community Process will be instituted shortly. Java Specification Requests (JSRs) which have previously been submitted will continue to be considered using the 1.0 process unless they request to be moved to 2.0. (Sun will be moving all the JSRs that it chairs to the 2.0 process.) The major difference in the process is an Executive Committee composed of representatives from about a dozen companies will have control of the process at critical decision points, (Previously, Sun had complete control.) These points are:

1. At initial submission
2. Before the public draft
3. At the end of the process

Individuals named to an expert group can now participate in work on that JSR at no cost, although signing an agreement with Sun is still required.

Apparently, the Java Grande Forum cannot be listed as an endorsing party for JSRs since it is not a registered participant in the process.

1. Determine how the Java Grande Forum could be an official participant in the Java Community Process. (Boisvert, Lindholm)

IBM submitted this JSR several months ago. The JSR contains the following.

• A new floating-point mode, fpfast, indicated with the class or method keyword fastfp would be introduced.

• Fused multiply-addition instrutcions (FMAs) would be allowed in fpfast mode.
• Use of associativity in compiler optimizations will be considered.
• Other compiler optimizations will be considered.
• Default and fpstrict modes will be considered legal implementations of fpfast, i.e., use of these optimizations is optional.
• These changes would be applied only to all Java platforms supporting floating-point arithmetic.

The actual impacts on the Java language would be minimal. Compilers would need to detect the new keyword and set a bit in the class file to indicate fpfast mode. The reflection API must be modified to sense this bit and return an appropriate indicator. Since optimizations are all optional, no additional changes need be made to assure conformance.

Sun responded fairly positively, but suggested that Sun lead the expert group. Tim Lindholm will do this.

The working group discussed whether the JSR should be more specific before submission. It was decided to continue the JSR in the current form.

Java Grande has already submitted its fastfp and array class JSRs under the 1.0 process. (This was actually done by IBM.) We should consider whether it is better to switch to the 2.0 process.

1. Notify the working group by email of the status of the fastfp JSR. Solicit participation in a possible experts group. (Boisvert)
2. Decide whether to continue fastfp in the JCP 1.0 or JCP 2.0. (Moreira, Snir)
3. Incorporate minor changes into the fastfp JSR as requested by Sun and resubmit. (Moreira, Snir)

IBM submitted this JSR several months ago. The JSR proposes the multidimensional array API developed and implemented by IBM. Sun had several initial requests regarding the JSR.

1. Sun doesn't like the name "array" for this package. (It is already in use.) They suggested "matrix", which would not be acceptable to the Working Group. The Group suggests "multiarray".
2. Sun doesn't want dependencies between JSRs. Since references to array syntax is not critical in this JSR they will be removed.
3. The JSR originally called for an extension to the Java Native Interface (JNI) to provide a method for extracting multidimensional array elements in a particular order. However, Sun does not want to make changes to JNI. Instead, extractor methods will be added to the proposed array API.

The JSR contains the statement that the layout of the internal array is "logically" row-wise, but does not specify a physical layout. This allows compilers the greatest freedom to perform optimizations (by picking a layout that is best for a particular code). Others counter that this relies on compiler technology that may not be available for some time. Library developers need to know what to do today. For this they need to know the physical layout, and, in particular, need to obtain aliases to array sections so that they can operate on the internal data structure directly. The key point in the API where this disagreement shows up is in methods for extracting array sections: should this be a copy or should it be a pointer to the internal data structure. These issues may not be able to be resolved until later in the JSR process.

1. Decide whether to continue the multidimensional array API with the JCP 1.0 or to jump to 2.0. (Moreira, Pozo)
2. Modify the multidimensional array API JSR to accommodate the requests of Sun and resubmit. (Moreira, Pozo)

Roldan Pozo and Jose Moreira reported progress on the draft of a JSR for a Java language extension to introduce bracket notation for multidimensional arrays, e.g. a[i,j]. This new notation would be mapped to the standard multidimensional array class.

Some discussion ensued regarding whether Fortran-90-like array sections should be admitted. Most felt that this would complicate the JSR and jeopardize its chances. Instead, the JSR will focus exclusively on elemental access only.

It was not clear how to write the JSR without reference to the multidimensional array class JSR on whose approval this depends.

Considerable skepticism was aired regarding this JSR's chances. If multidimensional array syntax is to be based on the array class, then this class would have to be made part of the Java core. This class is quite large. This would conflict directly with current emphasis on keeping the footprint of the Java core small, especially if the new syntax is perceived as being important only to a "niche market".

An alternative approach was also discussed. Instead of introducing a new syntax into the Java language itself, preprocessors or integrated development environments (IDEs) could be developed to support multidimensional array syntax. These could support improved readability of programs for Grande applications without the need for a change to the core language.

Nevertheless, the multidimensional array syntax proposal will be submitted.

1. Finalize draft of the multidimensional array syntax JSR and circulate in the Java Grande Forum for comments. (Pozo and Moreira)

Joe Darcy reported on his work with Michael Philippsen on introducing a complex data type to Java. The goal is to make complex behave exactly like a primitive type. It would be implemented by translation to calls to methods in an associated complex class. There would also be a purely imaginary data type. Careful description of the semantics and implementation of complex is quite difficult. Thus far, the basic operations have been defined. All cases where these touch the current language spec have been identified and documented. Work on specification of the elementary functions is in progress. Proper definition of branch cuts and corner cases will be a challenge. Good reference implementations may be difficult to construct. Dave Hare, who has considerable experience with the development of complex functions in Maple, has agreed to participate in this project.

1. Complete development of draft complex JSR and submit to Java Grande for further review. (Darcy, Philippsen, Hare)

Tim Lindholm described the changes in the elementary functions that have been included in Java 1.3 as a result of discussions in the Numerics Working Group. Previously, the behavior of the elementary functions was specified to be those results produced by a straightforward translation of fdlibm to Java. In practice, this specification was being ignored. The new specification is as follows.

• Elementary functions in java.lang.Math are required to produce results which deviate from the exact result, correctly rounded, by at most 1 unit in the last place (ulp). In addition, the results returned must be monotone in any interval in which the true function is monotone. The algorithms of fdlibm satisfy this requirement.

• A new class, java.lang.StrictMath has been added which contains the same methods. However, these retain the original math library semantics. In principle, these should produce the same results on all platforms.

Sun's JDK 1.3 contains fdlibm in C. Versions for the Intel processor that use hardware sine and cosine have been developed and will be introduced in JDK 1.3. These perform their own argument reduction, since the x86 functions are only valid for arguments whose size is less than 2⁶³. The existing C implementation in StrictMath is fairly well behaved, but requires some care as compiler optimizations can break reproducibility. Thus, the C version introduces some fragility in implementations. It is expected that a version of fdlibm in pure Java, based on those developed by John Brophy at VNI, will be incorporated into java.lang.StrictMath at some point in the future. Such a version would be immediately portable to implementations with conformant floating-point, reducing fragility (and probably also footprint). A pure Java version would probably also, in the short term, reduce performance somewhat, but given the looser definition of java.lang.Math, there is less pressure on java.lang.StrictMath to yield top performance.

1. Complete preparation of fdlibm in Java for inclusion into java.lang.StrictMath. (Lindholm, Brophy)

The Scimark benchmark of NIST was briefly discussed. Several suggested that Scimark should include tests to insure that the correct answer is being produced. These should take the form of simple "sanity checks" to catch gross defects in the Java environment (or blatant cheating). It was agreed that such checks should not have the aim of verifying conformance of the Java platform to relevant specifications.

1. Add "sanity checks" on results to Scimark. (Pozo)

The following additional issues were discussed.

Cliff Click, Sun

Vladimir Getov

The following people sent their regrets at their inability to attend.

John Brophy, Visual Numerics

Sid Chatterjee, Univ. North Carolina

Geoffrey Fox