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. > |
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 |
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 |
Free forum by Nabble | Edit this page |