Re: Fw: Question about JEP 306.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Fw: Question about JEP 306.

David Holmes
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:
>
>
> 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.
>
> There could be an associativefp option. 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
>
>
> -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) ...
>
> 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.
>
Reply | Threaded
Open this post in threaded view
|

Re: Fw: Question about JEP 306.

joe 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
Reply | Threaded
Open this post in threaded view
|

Re: Fw: Question about JEP 306.

joe darcy
PS With a more concrete example below....


On 12/5/2017 6:55 PM, Joseph D. Darcy wrote:
> Hello,
>
> On 12/5/2017 5:07 PM, David Holmes wrote:
>> Adding core-libs-dev as both mailing lists are named in this JEP.
>

[snip]

>>> 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.

Consider the square root function on the interval [1, 2), that is the
half-open region that includes 1 but does not include 2. This
corresponds to the floating-point numbers with an exponent of 0. There
are 2^52 floating-point values with this exponent. Mathematically,
sqrt(1) = 1 and sqrt(2) ~= 1.414... Therefore, in floating-point, for
values 1.0 <= x < 2.0, the result of sqrt(x) also has an exponent of 0.
Now we see that there are 2^52 floating-point values with an exponent of
0 and taking a square root of those values will only yield about 0.414 *
2^52 distinct answers. Therefore, we see that using a fixed
floating-point precision, the square root function on [1.0, 2.0)
*cannot* be inverted losslessly since only a minority of the input
elements have distinct answers.

HTH,

-Joe