Legend has it that after the ancient Greek Hippasus shared with his
fellow travelers the elegant proof [1] that the square root of 2 is not
a rational number, he was thrown off the ship by Pythagoreans outraged
that such numbers should exist. Hippasus subsequently drowned. Whatever
catharsis was released by his death did not change the fact that
mathematically sqrt(2) cannot be exactly represented by the ratio of two
integers.
Rational numbers are simple and elegant. However, in many areas we
cannot limit ourselves to dealing with rational numbers since values
like sqrt(2) cannot be accommodated. To greatly abbreviate the
development of different kinds of numbers, real numbers are commonly
used, despite their complexities, since they contain their limits,
meaning that transcendental values like pi are inside the system.
Floating-point arithmetic is a systematic approximation to real
arithmetic, an approximation with pragmatic compromises to facilitate
calculation on computers. Floating-point numbers can represent numbers
over vast scales and are (typically) fixed-sized. These aspects of
floating-point arithmetic force most field axioms to fail to hold, field
axioms being the familiar properties of arithmetic such as addition
being associative ((a+b) + c == a + (b+c)).
Other fixed-size approximations that have been explored, such as
fixed-slash and floating-slash arithmetic, have been found to have worse
computational shortcomings than floating-point arithmetic.
It is true that using a binary floating-point representation rather than
a decimal floating-point representation can cause additional surprises
since 1/10 is not exactly representable in binary. However, all the
field axioms that fail to hold for binary floating-point arithmetic also
fail to hold for decimal floating-point arithmetic. In addition, the
distances between adjacent decimal numbers makes a larger relative jump
(ten-fold) across exponent boundaries than for binary (doubling).
The IEEE 754-2008 standard incorporated decimal arithmetic into an
update of the 1985 version of the standard. This included fixed-size 64
and 128 bit decimal formats, amenable for hardware support. However, few
architectures have added such support.
Moreover, the roundoff errors from floating-point computation are only
one source of errors in a computation. *Even if arithmetic were done
exactly, numerical analysis would still be needed.* As numerical analyst
Nick Trefethen has said "If rounding errors vanished, 95% of numerical
analysis would remain." For example, exact arithmetic does not remove
modeling error, where the model does have sufficient fidelity with
reality. Many calculations involve sums of an infinite number of
decreasing terms so truncation errors occurs for the tail of the total
sum once the terms are no longer included.
The bugs have you filed and the emails you have sent to this alias are
all known situations and have all received responses:
JDK-8190947 -- Insufficient arithmetic Behaviour
Closed -- will not fix, including citations to additional
explanations of floating-point.
JDK-8197995 - BigDecimal and BigInteger Defaulting Behaviour
Closed -- not an issue, long-existing documentation describes
exactly how to avoid the reported problem.
JDK-8190991 - Forward and Inverse operations accuracy.
Closed -- not an issue. With fixed-precision, it is not possible to
invert operations over the entire domain, as previously discussed on
this list
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050393.html.
JDK-8190946 - There is no elementary functions support for
BigDecimal and BigInteger.
Closed as a duplicate of JDK-4297957, which in turn was created in
1999 and closed as will not fix in 2006.
Repeatedly ignoring these responses and the reasons given for them will
not make advancing your cause easier and wastes the time of those
crafting the replies.
To examine a few of these more closely, for JDK-8190991: "Forward and
Inverse operations accuracy" the responses give examples where for a
fixed-precision result, the function cannot be exacted inverted even in
the case where the true function is monotonically increasing (where it
is defined), like square root. The concrete example previously sent to
core libs: sqrt on the domain [1, 2) is in the range [1, ~1.4). From the
pigeon-hole principle, this cannot be in inverted in the same precision
since (of necessity) multiple elements of the domain map to the same
element in the domain. In fact, a majority of elements of range must
have two or more corresponding domain elements.
For JDK-8190946: "There is no elementary functions support for
BigDecimal and BigInteger", it is a true observation that BigDecimal and
BigInteger offer few elementary math functions, many fewer functions
than are supported for double in java.lang.{Math, StrictMath}. It is
also true that a larger suite of math library methods for BigDecimal
would be useful to some users. However, the mere fact that a set of new
library methods would be useful for some users is *not* sufficient cause
to have the JDK team work to develop, test, and maintain such a library.
It is perfectly acceptable and in many ways preferable for limited-use
libraries to be developed outside of the JDK and not shipped as part of
the JDK.
One of the use-cases for the value type changes being worked on in
Project Valhalla is lower-overhead for numerical types, such as
BigDecimal and BigInteger and potential classes like complex, etc. IMO,
it would also be reasonable to have syntactic support for operators on
such types.
There are no prospects for a fundamental redefinition of the
floating-point semantics of the Java language and VM. It is possible a
faster and looser mode will be defined at some point, but altering the
default is extremely unlikely. Long-term, decimal-based arithmetic (and
other kinds of arithmetic) may get better support as a consequence of
the features in Valhalla. Filing additional bugs or additional emails to
this alias will not change any of this or make it happen faster.
A few notes on what this mailing list is and is not. This list and other
lists under of the OpenJDK umbrella are forums for people participating
in OpenJDK development and who want to be informed about OpenJDK
development. These lists are not a free support channel. These lists are
not a forum to drop in, issue demands for large projects without so much
as an offer of assistance, and then check back a few months later to see
why more progress hasn't been made.
-Joe
[1] Assume sqrt(2) is a rational in lowest terms, p/q. Then, by
definition, 2 = (p^2)/(q^2) and therefor 2(q^2) = p^2. Consequently p^2
is even which implies p is even as well. Let r = p/2; r is an integer.
p^2 = (2r)^2 = 4r^2. Substituting, 2(q^2) = 4(r^2), reducing q^2 =
2(r^2). Therefore, q^2 is even and q is even as well. However, we have
reached a contradiction. If both p and q are even, then p/q is *not* in
lowest terms. Therefore, there is no rational number which is the square
root of 2.
