JDK-4141677 : The spec for java.lang.Math should not be written in C.
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.1.6,1.4.1
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: linux,solaris_2.5
  • CPU: x86,sparc
  • Submitted: 1998-05-26
  • Updated: 2015-07-14
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbd_majorUnresolved
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
Name: mgC56079			Date: 05/26/98



The licensee has a problem with java.lang.Math.pow function.
The behaviour of pow in their system is different from reference implementation.
However, there is no clear spec for mathematical functions. 
The JLS refers to C implementation of fdlibm as a spec.
This is not a good thing. We cannot rely on C behaviour in the JLS.
A possible solution is to provide reference implementation of java.lang.Math in java.

> Date: Thu, 21 May 1998 18:22:50 +0900
> From: Shigeru Santo <###@###.###>
> To: ###@###.###
> Subject: The certification process
> Product Name: Developer's Kit for Java
> Platform:      HI-UX/WE2 (Hitachi's unix platform)
> Based on:      JDK 1.1.6 Solaris reference
> 
> The certification process:
>  We have run all of the test in the JCK 1.1.6a, and get the following
> failed items. All other items have been passed.
>  
>  I believe all of these failed items are allowable to get the Java logo.
>  So, I would like you to give us a right to contact with JavaSoft
> Marketing Communications to request the logo artwork.
> 
>  The explanations for the each failed items:
> 
> *** Case (1) to (4): The result from our pow() library is slightly
> different from the result in the Solaris, and all these test cases are
> expecting exactly the same return value as the Solaris's pow().
> 
>  For example:  
>    pow(2.0, -51.0)
>      0x3CBFFFFFFFFFFFED^[$B!!!!!!!!!!^[(JHI-UX/WE2
>      0x3CC0000000000000^[$B!!!!!!!!!!^[(JSolaris
> 
>  I believe this is allowable difference.
> 
>  I think you should not expect exactly the same return value as your
> math library that is treating the floating point value.
>  The result of such a library must be checked by a range,
> e.g. low < result < high.
>
>  Because the result would be slightly differs by the algorithm that is
> chosen by the library, and JLS does not define the algorithm of the
> library.
> 
> =================== The results ==================================
> 
> --------------------   pow() problem -----------------------------
> 
> (1)/java -verify
> javasoft.sqe.tests.vm.classfmt.cpl.cpldbl005.cpldbl00501
> ----------ref:testExecute(1/14)----------
> invalid value
> ----------log:testExecute(0/0)----------
> 
> 
> (2)/java -verify
> javasoft.sqe.tests.vm.classfmt.cpl.cplflt005.cplflt00501
> ----------ref:testExecute(1/14)----------
> invalid value
> ----------log:testExecute(0/0)----------
> 
> (3)/java -verify
> javasoft.sqe.tests.api.java.lang.Float.intBitsToFloat25Tests
> ----------ref:testExecute(56/2917)----------
> 
> STATUS:Failed.tests: 16; passed: 10; failed: 6; first test case failure:
> 0:1
> command result: Failed. tests: 16; passed: 10; failed: 6; first test
> case failure: 0:1
> test result: Failed. tests: 16; passed: 10; failed: 6; first test case
> failure: 0:1
> 
> (4)/java -verify
> javasoft.sqe.tests.api.java.lang.Double.longBitsToDouble4Tests
> ----------ref:testExecute(42/2235)----------
> 
> STATUS:Failed.tests: 13; passed: 9; failed: 4; first test case failure:
> 0:1
> command result: Failed. tests: 13; passed: 9; failed: 4; first test case
> failure: 0:1
> test result: Failed. tests: 13; passed: 9; failed: 4; first test case
> failure: 0:1

======================================================================
###@###.### 2004-11-11 21:46:39 GMT

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon
15-08-2004

EVALUATION We should change the spec to use the Java version of fdlibm, which does exist. However, the problem is not as bad as the submitter believes. The fdlibm library produces IEEE compatible results in a portable manner, so it seems tha things are well specified. gilad.bracha@eng 1998-05-27 Changing category to classes lang since the jls no longer inclues the specification for the libraries. ###@###.### 2003-07-29 No time for porting in Tiger; should be done in a future release. Would provide insurance against certain kinds of porting issues; see 4880538. ###@###.### 2003-09-08
29-07-2003