Name: rmT116609 Date: 09/01/2004


A DESCRIPTION OF THE REQUEST :
Currently Java has floating point and integer numeric datatypes. Floating point operations are prone to errors that affect the accuracy of the result. Interval arithmetic is one proposed solution to this problem.

JUSTIFICATION :
1. There is plenty of evidence that floating point errors can significantly affect the output of a simulation model. For one paper on this in the agent-based modelling community, see http://www.uni-koblenz.de/~kgt/ESSA/ESSA1/Polhill-Izquierdo-Gotts.pdf

2. Interval arithmetic is a possible solution, argued by Donald Knuth (Art of Computer Programming vol 2.) to show considerable promise. Floating point expert William Kahan also argues that interval arithmetic, unlike other remedies to floating point problems, does not lull the user into a false sense of security (http://www.cs.berkeley.edu/~wkahan/improber.pdf).

3. There is a growing community of scientists using Java to program simulations, particularly in the agent-based modelling community. (see http://repast.sourceforge.net/, http://cs.gmu.edu/~eclab/projects/mason/, http://wiki.swarm.org/). If Java provided an interval arithmetic datatype it would stand head and shoulders above other popular programming languages (e.g. C, C++) that make no such provision, and make a significant contribution to establishing its credentials as a scientific programming environment.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Joe Darcy's Borneo extensions give one approach to implementing interval arithmetic (http://www.jddarcy.org/Borneo).

An Interval class (inheriting from Number) would use the IEEE 754 directed roundings to establish the bounds on the results of a series of operations. The correct result is known to lie within these bounds.

Comparison operations would somehow enable the programmer to detect that there was uncertainty in a comparison, either by throwing an exception (which might be a bit extreme) or by setting a sticky flag indicating that a comparison had an issue.

Uncertainty in a standard comparison operator is indicated when the comparison operator would not return the same boolean result for all members of the intervals being compared. This is a point when floating point errors in successive computations could be causing the code to behave other than in would if real numbers were being used instead of floating point. If such a condition never occurs in a simulation model, then it is known that the model is behaving correctly regardless of any floating point errors that have occurred.

Modal comparison operators should also be provided -- e.g. <>> (possibly greater than -- returns true iff at least one member of the LH interval is greater than the RH) and []> (necessarily greater than -- returns true iff all members of the LH interval are greater than all members of the RH), <>==, []==, <>!=, []!=, etc.

The standard comparison operators could use the modal ones to detect warning situations.

e.g. the expression X > Y would return true if X []> Y, otherwise, it would check if X <>>Y, and if so set the comparison uncertainty sticky flag to true before returning false.
(Incident Review ID: 301604)
======================================================================