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
