Math project or subproject (original) (raw)

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 http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-January/000225.html (contribution proposals) http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-February/000229.html (proposals approved) http://mail.openjdk.java.net/pipermail/core-libs-dev/2008-February/000236.html (patch submitted) This patch is still not in OpenJdk tree.
  2. Double.parseDouble(String s) loops infinitely on some inputs http://bugs.sun.com/view_bug.do?bug_id=4421494 (one-line fix was suggested in bug database comment in 2004) http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003153.html (fix was submitted again together with tests) http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003182.html (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). http://www.scala-lang.org/ http://projectfortress.sun.com/Projects/Community/ http://futureboy.homeip.net/frinkdocs/ http://fantom.org/

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 Project.

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: BINARY128, BINARY80.
  6. Universal Comparator to compare values of different subclasses of Number with each other. Different quiet and signalling relational operators mentioned in IEEE 754r standard.
  7. Implementation of forthcoming P1788 Interval Arithmetic standard http://grouper.ieee.org/groups/1788/

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. http://coq.inria.fr/ http://lipforge.ens-lyon.fr/www/pff/ http://gappa.gforge.inria.fr/ http://why.lri.fr/ http://krakatoa.lri.fr/

What do people think about a Math project or subproject ?

-Dima

More information about the core-libs-dev mailing list