Java Solaris Communities Sun Store Join SDN My Profile Why Join?
 
Bug Database
Bug Detail
Quick Lists
Top 25 Bugs
Top 25 RFE's
Recently Closed Bugs
Printable Page Printable Page


Bug Database
Bug ID: 5095286
Votes 15
Synopsis Support IEEE 754 sticky bit exception flags
Category java:classes_lang
Reported Against 1.4.2
Release Fixed
State 11-Closed, Will Not Fix, request for enhancement
Priority: 4-Low
Related Bugs 5095600
Submit Date 01-SEP-2004
Description




A DESCRIPTION OF THE REQUEST :
Currently Java provides no support for inspecting the IEEE 754 sticky bit exception flags to check for floating point errors in double and single precision operations. For those using Java as a simulation modelling platform (and there is a growing community particularly in agent-based modelling -- see http://repast.sourceforge.net/, http://cs.gmu.edu/~eclab/projects/mason/, http://wiki.swarm.org/), this is a serious issue.

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. Java is a very useful programming environment for scientific simulation modelling, through its platform independence. This enables scientists to share models and repeat each other's results without having to worry about portability issues. As a scientific programming environment, full support for the IEEE 754 standard should be a requirement. Java has been criticised by floating point experts for not doing this (http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf). Part of this means providing support for the IEEE 754 exception flags. Not doing so means that in the end, respectable scientists will have to move away from Java.

3. It is extremely unlikely that Java will be run on a chip that does not support IEEE 754, as this standard has been around for nearly 20 years. However, a method could be provided in the Double class returning a boolean indicating whether sticky bit support is available on this platform, or the accessor methods could throw an exception.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
There are numerous ways this could be implemented. Joe Darcy's Borneo extensions are one idea (http://www.jddarcy.org/Borneo). A simple approach to just implement exception flags could be to introduce class methods to the Float and Double classes enabling inspection and clearing of the sticky bits.

e.g.

public static boolean getImprecisionStickyBit();
public static boolean setImprecisionStickyBit(boolean value);

public static boolean anyStickyBitSet();
public static boolean clearStickyBits();

Alternatively, a floating point sticky bit class could be defined containing these methods, and accessor methods provided from Double and Float

e.g.

public static FloatingPointStickyBits getStickyBits() throws StickyBitsNotSupportedException;

public static FloatingPointStickyBits setStickyBits() throws StickyBitsNotSupportedException;
(Incident Review ID: 301596) 
======================================================================
Work Around
N/A
Evaluation
The challenge to supporting the IEEE 754 sticky bits is not adding the methods to query and set the state, the challenge is for the rest of the system and libraries to cooperate to make the reading of the state predictable and therefore useful.  Some of the hazards of having access to the state without coordinated system support are detailed in the Borneo specification.

An approach less ambitious than Borneo for accessing the sticky flag state would be to only define values for the state in methods and constructors that were marked in some way.  This would minimize the opportunity cost of lost optimizations for methods that don't care about such state.  However, any such approach will require changes to the Java language and virtual machine.

  xxxxx@xxxxx   2004-09-01
While there are definately use cases and algorithms that depend on access to the sticky flags, adding reliable support would be a large undertaking with limited benefit.

Closing as will not fix.
Posted Date : 2010-01-12 00:47:18.0
Comments
  
  Include a link with my name & email   

Submitted On 24-SEP-2004
esam_sun
This is an urgent fix.



PLEASE NOTE: JDK6 is formerly known as Project Mustang