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
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
More information about the core-libs-dev
mailing list