Math project or subproject

Dmitry Nadezhin Dmitry.Nadezhin at Sun.COM
Fri Jan 29 09:02:29 UTC 2010

In my previous post I discussed choice criteria for performance 
enhancements in math libraries.

I guess that in production projects Jdk 1.6 and Jdk 1.7 the main choice 
criteria is stability.
This explains why changes to math stuff in Java are almost impossible.
Here is a pair of examples:
1) The Karatsuba multiplication in BigInteger
(contribution proposals)
(proposals approved)
(patch submitted)
This patch is still not in OpenJdk tree.
2) Double.parseDouble(String s) loops infinitely on some inputs
(one-line fix was suggested in bug database comment in 2004)
(fix was submitted again together with tests)
(fix was scheduled for verification)
This patch is still not in OpenJdk tree.

I respect our "Java Floating-Point Czar" for keeping stability of 
mainstream Java.
However, I suspect that some OpenJdk users prefer enhancements and bug 
fixes of old bugs in math libraries
in exchange for a small risk of new bugs. Perhaps some new languages may 
need enhancements in OpenJdk math
(scala, fortress, frink, fantom).

What about more rapid enhancement of OpenJdk math in some project 
related to but separate from OpenJDK 6 and (Open) JDK 7 ?
This may be a new Math project or a subproject of the Da Vinci Machine 

I see such works which can be done in such a project.

I) Jdk changes
1) bug fixing of known math bugs from bug database;
2) creating microbenchmarks for performance enhancements request
    Keeping a collection of alternative implementations and picking 
currently fastest implementation
3) Static methods which performs arithmetic operations on doubles with 
RoundingMode.FLOOR and
RoundingMode.CEILING for use in interval computations.
4) Arbitrary-precision classes:
  Rational - rational numbers together with infinities and signed zero
  Binary - floating-point binary numbers
5) Classes for some particular floating-point binary formats:
6) Universal Comparator<Number> to compare values of different subclasses
    of Number with each other. Different quiet and signalling relational 
   mentioned in IEEE 754r standard.
7) Implementation of forthcoming P1788 Interval Arithmetic standard

II) HotSpot changes.
I consider useful to intrinsify some methods from above (3),(4),(5),(7).,

III) Quality
  Perhaps the math libraries are a proper subject for Formal Verification.
  Operation on numbers are easy to specify by formal tools.
  It is easy to make long-live bugs in math libraries which can be 
detected by attempt to prove.
  There are already tools to assist formal proofs.

What do people think about a Math project or subproject ?


More information about the core-libs-dev mailing list