Issue  Complex numbers are extremely important for numerical computing and should be available in Java. Their use should be convenient and operations on them should be efficient as fundamental data types (e.g. double). 
Solution A  Create the obvious Complex class and make it a standard API. 
Pros  This is easy to do and can be done immediately. 
Cons  Leads to unreadable and inefficient code. 
Solution B  Modify the Java language to include complex as a base type. 
Pros  Leads to natural, readable code which is easily optimized by compilers and runtime JITs. 
Cons  Requires a major modification to the Java language to satisfy a relatively small segment of Java users. 
Solution C  Introduce "lightweight" and operator overloading to Java. Lightweight (or valuebased) classes would be designed to not suffer from the usual object overhead (e.g. have support in the language and/or VM to minimize heap allocation). A lightweight complex class would, presumably, be more efficient than a regular class, and operator overloading could make its use as natural as for the base arithmetic types double and float. 
Pros  This represents a good compromise, and the new language features required would benefit many other fundamental numerical classes which share the need for efficiency and usability. 
Cons  This requires two major changes to the Java language: lightweight classes and operator overloading. 
Note: in either solution, existing APIs must be extended, e.g. Math.abs(), Math.cos(), etc. to work with complex numbers.
Issue  Other arithmetic data types are of considerable interest to the numerical community. The two most often cited are interval arithmetic, and (arbitrary) multiple precision arithmetic. 
Solution  Add intervals and arbitrary precision floats as base types in Java. 
Pros  This will make these important types most easily accessible to the community. 
Cons  This requires significant modification to the language to satisfy a small community of Java users. 
Solution  Define standard classes for interval and multiple precision arithmetic. Implement as "lightweight" classes and use operator overloading to make programs using these comprehensible. 
Pros  This is a good compromise, satisfying the numerical community while only requiring new language features (lightweight classes and operator overloading) which benefit a much wider range of user. 
Cons  This requires significant new additions to the language. 
Issue  Java's wordy syntax is excessively burdensome when used to define elementary mathematical classes such as complex arithmetic and array operations. 
Solution  Add operator overloading to Java. 
Pros  Operator overloading not only enables a natural and elegant syntax for complex arithmetic and arithmetic on arrays, but extends to elements of any algebraic field, including extended precision numbers, rational numbers, matrices, vectors, tensors, grids, etc. (java.Math already includes BigDecimal and BigInter classes that could benefit from operator overloading). 
Cons  Operator overloading can be abused to generate hardtoread code by redefining familiar symbols into unintuitive operations. 
Issue  Code management and reuse in numerical programs is very difficult without a powerful and standardized preprocessor. 
Solution  Add a mechanism similar to C++ templates to Java. Even a simplified version could still provide many advantages. 
Pros  One obvious use of templates is in developing float and double versions of the same numerical routine. But more important is the ability to describe a numerical algorithm, say an iterative linear equation solver, in an "generic" way, without explicit mention of the matrix structure or storage details. Finally, advanced techniques like template expressions can be used to deal efficiently with array/vector operations, unroll loops, and fuse large array expressions into a single loop. 
Cons  Template mechanisms introduce tremendous complexity into the language. This diminishes one of the key attractive features of Java  its simplicity. Templates also have a series of practical problems, mostly related to their implementation. Template codes can often lead to code bloat (since a separate routine is generated for each instantiation). They can be difficult to debug, depending on how well the debugger understands instantiations. Nested templated also present implementation problems. A quick read of the messages related to template problems in C++ news groups should give one a good idea of what to expect. 
Issue  Requiring that Java programs produce bitwise identical floatingpoint results in every JVM seems to be not only unrealizable in practice, but also inhibits efficient floatingpoint processing on some platforms. For example, it precludes the efficient use of floatingpoint hardware on Intel processors which utilize extended precision in registers. 
Solution A  Relax the requirement of reproducibility for floatingpoint, admitting the use of IEEE extended in any intermediate computation. 
Pros  This corresponds to existing practice in the numerical community, allows the use of extended precision hardware, and and provides improved results in most cases. 
Cons  The certainty of exact reproducibility must be given up. This may be a burden for a few extreme cases in which absolute control of floatingpoint computation is necessary. 
Solution B  Provide a parameter within the JVM which allows users to permit the use of extended precision in intermediate computations. 
Pros  This allows the current Java specification to remain as the default, but allows it to be overridden by the user for highperformance applications. 
Cons  It will be difficult for the user to communicate this parameter to JVMs which are buried within other applications (e.g., Web browsers). This requires that JVMs implement two different types of floatingpoint arithmetic for hardware that has IEEE extended precision. 
Solution C  Introduce a new class and methods modifier looseNumerics, which permits JVMs to use IEEE extended precision in intermediate results while executing methods in its scope. 
Pros  This allows the existing Java specification to remain the default, while allowing developers to specify that higher performance is more important than exact reproducibility for the given class. 
Cons  The looseNumerics will be used on most classes which heavily use floatingpoint arithmetic, and hence the converse solution would be simpler (see below). This requires that JVMs implement two different types of floatingpoint arithmetic for hardware that has IEEE extended precision. 
Solution D  Relax the requirement of reproducibility for floatingpoint, admitting the use of IEEE extended in any intermediate computation. Introduce a new class and method modifier strictNumerics, which requires JVMs to the existing Java specification while executing the methods within its scope. 
Pros  This corresponds to current practice in the numerical community, while providing the ability to impose stricter floatingpoint requirements for those few applications that may need it. 
Cons  This requires that JVMs implement two different types of floatingpoint arithmetic for hardware that has IEEE extended precision. 
Issue  Requiring that Java programs produce bitwise identical floatingpoint
results in every JVM prevents use of certain aggressive compiler
optimizations that can lead to more efficient code. Examples
include the following

Solution A  Provide a parameter within the JVM which allows users to permit the use of aggressive compiler optimizations of this type. 
Pros  This allows the current Java specification to remain as the default, but allows it to be overridden by the user for highperformance applications. 
Cons  It will be difficult for the user to communicate this parameter to JVMs which are buried within other applications (e.g., Web browsers). 
Solution B  Introduce a new class and method modifier idealizedNumerics, which permits JVMs to use optimizations of this type while executing the methods within its scope. 
Pros  This allows the existing Java specification to remain the default, while allowing developers to specify that higher performance is more important than exact reproducibility for the given class. 
Issue  Roundtonearest is the only IEEE 754 rounding mode recognized by Java. While this is adequate in most cases, some specialized processing, such as interval arithmetic, would benefit greatly from more explicit control of the rounding mode (i.e., round up, round down, round to nearest) in specific instances. 
Solution A  Provide a procedure which allows one to select the global rounding mode. 
Pros  This provides easy control of the global rounding mode, and requires no significant change to the language. 
Cons  When the rounding mode is important to control, it is necessary to control it at a much finer level. This is awkward to do with a global switch. 
Solution B  Provide new language syntax that provides finer control of the
scope of rounding modes, e.g.

Pros  Provides tighter control on the scope of the rounding mode. 
Cons  Requires new language syntax and semantics to implement. 
Solution C  Provide a new standard package that implements the elementary
arithmetic operations with each rounding mode. For example

Pros  This provides very tight control of the scope of the rounding mode, allowing different modes in a single expression. Compiler inlining or "lightweight" classes could make such operations fairly efficient. 
Cons  Expressions using controlled rounding modes are difficult to read. 
Issue  Currently Java admits only default actions when IEEE floatingpoint exceptions occur. Thus, for example, 1/0 produces Inf, 0/0 produces NaN, etc. and, since, arithmetic on these special quantities is completely defined, no trapping occurs. This, again, is sufficient for most applications. However, it is sometimes crucial to know if one of these special events has occurred. 
Solution  Allow hardware trapping on userselected IEEE floatingpoint exceptions. 
Pros  Enabling floatingpoint traps which terminate a program is quite useful for debugging. 
Cons  Providing a reasonable exception handler for such low level traps is difficult for users. Optimizing code in the presence of such traps is very difficult for compilers. 
Solution  Provide standard methods to determine whether a given IEEE floatingpoint exception has been raised, and to clear exceptions once tested. 
Pros  The latter is easy to implement exploit by working programs. 
Cons  This does not help in debugging. 
Issue  Java defines a single specific bit pattern to represent NaN. This is contrary to IEEE 754 which specifies a range of values, all of which represent NaN. This Java restriction is unnecessary. 
Solution  Simply remove the restriction, allowing all NaN representation admitted by IEEE 754. 
Pros  This will allow for more efficient programs, since NaNs will not have to be trapped and fixed. 
Cons  This add s yet another ambiguity which undermines the goal of producing bitwise identical results on all JVMs.. 
Issue  Numerical software designers typically take information about the
physical layout of data in memory into account when designing
algorithms to achieve high performance. For example, LAPACK uses
blockoriented algorithms and the Level 2 and 3 BLAS to localize
references for efficiency in modern cachebased systems. The fact
that Fortran requires twodimensional arrays be stored contiguously
by columns is explicitly used in the design of these algorithms.
Unfortunately, there is no similar requirement for multidimensional arrays in Java. Here, a twodimensional array is an array of onedimensional arrays. Although we might expect that elements of rows are stored contiguously, one cannot depend upon the rows themselves being stored contiguously. In fact, there is no way to check whether rows have been stored contiguously after they have been allocated. The possible noncontiguity of rows implies that the effectiveness of blockoriented algorithms may be highly dependent on the particular implementation of the JVM as well as the current state of the memory manager. 
Solution A  Define a new multidimensional array data type for Java whose memory layout would be defined (contiguous storage, rowwise, for example). Such arrays would use multidimensional array indexing syntax (i.e. A[i,j] rather than A[i][j]) to distinguish them from Java arrays of arrays. Threedimensional arrays are also quite common in applications and could be similarly included. 
Pros  This will provide programmers with a higher degree of certainty that data is laid out in a way that is optimal for their algorithm. Compilers will be able to exploit the data layout to optimize indexing in expressions involving arrays. 
Cons  This is a significant change to the Java language specification. Early evidence indeed shows that blockoriented algorithms can show significant performance increases with good JITs. While contiguity of rows may be the ideal case, its absence does not necessarily preclude improvement in performance for block algorithms. In one experiment with a blocked matrix multiply, the computation rate dropped from 82 Mflops to about 55 Mflops when rows were randomly permuted. On the other hand, for a naive nonblocked roworiented matrix multiply, the original 11 Mflop rate was unchanged when the rows were permuted. The important issue is reusing data that lies in cache. Noncontiguity of rows only means that the cache may be filled in smaller increments. 
Solution B  Define standard classes which house contiguously stored multidimensional arrays. These would be physically stored in a singly dimensioned Java array, with get and put methods that accessed individual elements based on two indices. 
Pros  This requires no change to the Java language. 
Cons  It is doubtful that such classes could be made as efficient as true multidimensional Java arrays. The classes would have to be "lightweight" and it would be very difficult for compilers to eliminate the overhead of explicit indexing. 
Solution C  Define an alternate "new" operation for arrays which required contiguous allocation. 
Pros  This requires only a small change to the Java language. 
Cons  This requires new functionality in the VM. For certain types of garbage collection, this would cause lead to more frequent failure to allocate arrays. 
Issue  In Fortran, subarrays of multidimensional arrays can be logically passed into subprograms by passing in the address of the first element along with subarray dimensions. Internally to the subprogram the subarray acts just like a multidimensional array. This greatly eases the implementation of many algorithms in numerical linear algebra, for example. Subarrays cannot be delivered to methods in this way in Java. 
Solution A  The subarray is first copied to a new appropriately sized array, and the new array is passed to the method. 
Pros  The procedure receives a real Java array and need not handle any special cases. 
Cons  Much inefficient data copying is performed. 
Solution  The entire array is passed to the method along with explicit index ranges which define the subarray. 
Pros  No explicit array recopying is required. 
Cons  Variants of methods that explicitly operate on subarrays must be developed; the coding and efficiency of these methods will be complicated by complex indexing computations. 
Issue  Some highperformance applications require extremely long arrays. Java's integer data type may not provide indices large enough to handle such arrays. 
Solution  Add a long integer data type to Java and allow it to be used in array indexing. 
Pros  This will simplify coding of applications with extremely large data sets. 
Cons  This will add a new data type to the Java language. 
Issue  Fortran 90 and MATLAB each allow array expressions for computation on entire arrays. They also use a very convenient notation to denote computation on subarrays, such as A(1:5) = B(2:6) + C(10:14). The usability of Java would be greatly enhanced with similar features. 
Solution  Extend the Java language to admit arithmetic expressions on full arrays, and introduce a notation like Fortran 90's for denoting subarrays for use in expressions. 
Pros  Such features greatly ease scientific computation which are typically heavily array oriented. They also provide an easier way for compilers to discover useful optimizations. This would provide a syntactic device for passing subarrays to procedures. 
Cons  This would be a significant new addition to the Java language. Passing subarrays to procedures this way is contrary to the object model on which Java is based. Thus, passing subarrays would probably have to be done as passbyvalue, which would be greatly inefficient. 
Issue  Array boundary checks can result in reduced performance. 
Solution  Add a "noboundarycheck" switch. 
Pros  This can be used to speed the performance for debugged applications. This already done in IBM's high performance Java compiler 
Cons  Boundary checks are one of the major reasons for the stability and security of Java code. Good compiler optimization might be able to prove a priori that all index expressions that occur inside of a given loop will be inside of array boundaries. Run time optimizations can be used to overlap bounds checks with floating point computations. Some studies have shown that such optimizations can lead to bounds checks which lead to only moderate overhead (e.g. 20%) to numerical computations. 
Issue  (any volunteers to write this?) 
Solution  
Pros  
Cons 
Issue  Basic data structures such as arrays, vectors, matrices, etc. are so fundamental to numerical computing, that there should be some consistent interface to these objects. This would avoid having each person to define their own. 
Solution  Provide a limited set of APIs for basic numeric objects. 
Pros  This is perhaps one of the most practical contributions we can make to the numerical community. Looking at C++, there are too many numerics codes that define their Vector objects, etc. These yield redundant, yet often incompatible class definitions. 
Cons  Not every one of these classes has a canonical representation. In particular, things like "Matrix" can have a multitude of meanings: a 2D array of doubles, an abstract linear operator, a sparse structure, etc. Some care in design has to be taken to provide a usable framework. 
Issue  The large body of Fortran scientific applications and libraries are not immediately available in Java. How can we best access them? 
Solution A  Provide a generic Fortran to Java translator. 
Pros  This would provide a 100% Java solution and retain the portability advantages of language and runtime system. 
Cons  Developing such a translator is very challenging, particularly for separate Fortran libraries. (One complication, among many, is that Java routines must reference the original array when passing subarrays through functions.) 
Solution B  Use JNI to integrate native methods. 
Pros  This is even easier with JNI component of JDK 1.1. One could also provide a specific API with objects like FortranArray2D, FortranArray3D, etc., and corresponding set(i,j)/get(i,j) methods to simplify Java codes that interfaced with Fortran. 
Cons  This has the same portability problems Fortran/C codes:

Solution C  Develop Java versions of these libraries. 
Pros  100% pure Java. Performance with latest JITs about 50% of optimized Fortran/C. (NIST is currently doing this with a tiny subset of the BLAS and LAPACK  see http://math.nist.gov/javanumerics/blas.html.) 
Cons  Writing libraries is lot of work. Performance with latest JITs is only about 50% of optimized Fortran/C. 
Last change to this page: April22, 1998