Math project or subproject

[Dmitry Nadezhin]

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<Number> 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