Fw: Question about JEP 306.

[Joseph D. Darcy]

Hello,

On 12/5/2017 5:07 PM, David Holmes wrote:
> Adding core-libs-dev as both mailing lists are named in this JEP.
>
> David
>
> On 6/12/2017 11:02 AM, A Z wrote:
>> -I have been wondering what interest, focus or progress
>>
>> is happening around OpenJDK JEP 306:

The rampdown phase for JDK 10 is beginning later this month. Since JEP 
306 is not in the process of being targeted for JDK 10, it will not be 
part of that release. However, it may be included in a subsequent JDK 
release; once we have sufficient clarity of the work needed and 
commitment to do the work, we target a JEP to a particular release.

>>
>>
>> http://openjdk.java.net/jeps/306
>>
>>
>> -As a Java feature request, could I request feature 306?
>> Underflow and overflow need to be eliminated
>> from double and float.

That is outside of the stated description of what the JEP aims to do. 
IEEE 754 arithmetic has rules about underflow and overflow, rules also 
generally followed by the Java language and JVM.

There are no plans to adopt a system like unums that avoid imprecise 
overflows to infinity by losing precision at values extremely large in 
magnitude.

>>
>> There could be an associativefp option.

Such an option is explicitly called out as a non-goal for JEP 306:

"Defining any sort of "fast-fp" or "loose-fp" (c.f. JSR 84: Floating 
Point Extensions) is out of scope for this JEP."

However, such an option could be done under another project. With 
suitable caveats about forward looking statements, no promises, etc. the 
possibility of a fast-fp option along with some of the technical issues 
that would need to be addressed is discussed in the last few minutes of 
my JVMLS talk from earlier this year:

     "Forward to the Past: The Case for Uniformly Strict Floating Point 
Arithmetic on the JVM"
     https://www.youtube.com/watch?v=qTKeU_3rhk4

The bulk of the talk is a justification for JEP 306.

>> It should also be the case
>> that there should be a round half up for the decimal place
>> beyond the last one in the float or double range, to help support
>> all notions of
>>
>> (pow(sqrt(3),2) == 3)  //true

Putting aside non-finite values like NaN and infinities, this identity 
is difficult to have hold in any fixed-precision system, including 
IEEE-style floating-point. The mathematical square root function in 
general returns irrational results for rational inputs so the result is 
fundamentally approximated.  If my rusty calculus is correct, for x >= 
0.25, the derivative of sqrt of x has magnitude less than one and is 
positive, meaning there exists some set of multiple input values that 
must get mapped to the same output value. Therefore, the information to 
do an exact inverse operation based on the output is not present just 
from a pigeon hole principle argument.

>>
>>
>> -The other thing that there should be is a StrictMath
>> that works for BigInteger and BigDecimal, allowing:
>>
>> pow(BigDecimal,BigDecimal)
>> pi(...)
>> e(...)
>> sin(Bigdecimal)
>> asin(Bigdecimal) ...
>>

Such methods would have utility and we've had enhancements request for 
those features

     JDK-4297957: Add algebraic and transcendental functions operating 
on BigDecimal

but we've closed them as will not fix.


>> which would allow for any power at all, as well as the nth root.
>> It is also a good idea to include a radians and degrees version
>> of all the trig functions.

See RFE

     JDK-6341878: add degree-based trigonometric methods to the Math class
     https://bugs.openjdk.java.net/browse/JDK-6341878

Cheers,

-Joe