Re: Floating Point and Arithmetic Changes for Java SE Lnguage

[Mario Torre]

I don’t remember ever having read another reply to this mailing list with
so much interest in years!

Cheers,
Mario
On Wed 7. Mar 2018 at 21:36, joe darcy  wrote:

> 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 

Re: Floating Point and Arithmetic Changes for Java SE Lnguage

[joe darcy]

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 

Re: RFR 8182684: Further clarify InputStream#available()

[Roger Riggs]

+1,

Thanks, Roger

On 3/7/18 1:57 PM, Brian Burkhalter wrote:

https://bugs.openjdk.java.net/browse/JDK-8182684
http://cr.openjdk.java.net/~bpb/8182684/webrev.00/

Unfortunately the change is somewhat obfuscated by reformatting. The main 
changes are the first sentence and the fourth paragraph.

A CSR will follow.

Thanks,

Brian

Re: RFR 8199258: BigInteger.bitLength() should explicitly specify behavior when the value is zero

[Lance Andersen]

looks fine
> On Mar 7, 2018, at 2:21 PM, Brian Burkhalter  
> wrote:
> 
> https://bugs.openjdk.java.net/browse/JDK-8199258
> 
> A diff is included below. If this looks good then a CSR will follow.
> 
> Thanks,
> 
> Brian
> 
> --- a/src/java.base/share/classes/java/math/BigInteger.java
> +++ b/src/java.base/share/classes/java/math/BigInteger.java
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights 
> reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -3556,8 +3556,8 @@
>  * Returns the number of bits in the minimal two's-complement
>  * representation of this BigInteger, excluding a sign bit.
>  * For positive BigIntegers, this is equivalent to the number of bits in
> - * the ordinary binary representation.  (Computes
> - * {@code (ceil(log2(this < 0 ? -this : this+1)))}.)
> + * the ordinary binary representation.  For zero this method returns
> + * {@code 0}.  (Computes {@code (ceil(log2(this < 0 ? -this : 
> this+1)))}.)
>  *
>  * @return number of bits in the minimal two's-complement
>  * representation of this BigInteger, excluding a sign 
> bit

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR 8199258: BigInteger.bitLength() should explicitly specify behavior when the value is zero

[Roger Riggs]

+1, looks fine.

Roger

On 3/7/2018 2:21 PM, Brian Burkhalter wrote:

https://bugs.openjdk.java.net/browse/JDK-8199258

A diff is included below. If this looks good then a CSR will follow.

Thanks,

Brian

--- a/src/java.base/share/classes/java/math/BigInteger.java
+++ b/src/java.base/share/classes/java/math/BigInteger.java
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -3556,8 +3556,8 @@
   * Returns the number of bits in the minimal two's-complement
   * representation of this BigInteger, excluding a sign bit.
   * For positive BigIntegers, this is equivalent to the number of bits in
- * the ordinary binary representation.  (Computes
- * {@code (ceil(log2(this < 0 ? -this : this+1)))}.)
+ * the ordinary binary representation.  For zero this method returns
+ * {@code 0}.  (Computes {@code (ceil(log2(this < 0 ? -this : this+1)))}.)
   *
   * @return number of bits in the minimal two's-complement
   * representation of this BigInteger, excluding a sign 
bit

RFR 8199258: BigInteger.bitLength() should explicitly specify behavior when the value is zero

[Brian Burkhalter]

https://bugs.openjdk.java.net/browse/JDK-8199258

A diff is included below. If this looks good then a CSR will follow.

Thanks,

Brian

--- a/src/java.base/share/classes/java/math/BigInteger.java
+++ b/src/java.base/share/classes/java/math/BigInteger.java
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1996, 2016, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1996, 2018, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -3556,8 +3556,8 @@
  * Returns the number of bits in the minimal two's-complement
  * representation of this BigInteger, excluding a sign bit.
  * For positive BigIntegers, this is equivalent to the number of bits in
- * the ordinary binary representation.  (Computes
- * {@code (ceil(log2(this < 0 ? -this : this+1)))}.)
+ * the ordinary binary representation.  For zero this method returns
+ * {@code 0}.  (Computes {@code (ceil(log2(this < 0 ? -this : this+1)))}.)
  *
  * @return number of bits in the minimal two's-complement
  * representation of this BigInteger, excluding a sign bit

RFR 8182684: Further clarify InputStream#available()

[Brian Burkhalter]

https://bugs.openjdk.java.net/browse/JDK-8182684
http://cr.openjdk.java.net/~bpb/8182684/webrev.00/

Unfortunately the change is somewhat obfuscated by reformatting. The main 
changes are the first sentence and the fourth paragraph.

A CSR will follow.

Thanks,

Brian

Re: RFR(XS) [closed] : 8198924: java/lang/StackWalker/LocalsAndOperands.java timeouts with Graal

[Ekaterina Pavlova]

Mandy, Brent, thanks for reviews.

Removing @bug will not allow to find this testcase by bugid (jtreg 
-bug:).
So, I think it is safe to omit only @summary.

regards,
-katya


On 3/6/18 2:30 PM, Brent Christian wrote:

Looks good, Katya - thanks.
I agree with omitting @bug and @summary from the second @test tag.

Thanks,
-Brent

On 3/6/18 1:59 PM, mandy chung wrote:

Running #1 and #2 when Graal is enabled is fine.

For the second @test, does it need @bug and @summary to run?  If not, I suggest 
to take it out as it's already mentioned in the first @test.

Mandy


On 3/6/18 1:45 PM, Ekaterina Pavlova wrote:

Hi all,

java/lang/StackWalker/LocalsAndOperands.java runs LocalsAndOperands 3 times 
with following set of jvm flags:
 1) -Xint -DtestUnused=true
 2) -Xcomp
 3) -Xcomp -XX:-TieredCompilation

When running with Graal as JIT (-XX:+TieredCompilation -XX:+UseJVMCICompiler 
-Djvmci.Compiler=graal)
3rd scenario could take more than 10 minutes and the test could fail by timeout.
Actually running LocalsAndOperands with Graal and with "-Xcomp 
-XX:-TieredCompilation" doesn't provide
big benefit and it would be reasonable to disable this scenario in case Graal 
is enabled.

Please review the change.

  JBS: https://bugs.openjdk.java.net/browse/JDK-8198924
   webrev: http://cr.openjdk.java.net/~epavlova//8198924/webrev.00/index.html

  testing: Tested by running the test in Graal as JIT mode.

thanks,
-katya

p.s.
 Igor Ignatyev volunteered to sponsor this change.

Re: Reactive Streams utility API

[Brian Goetz]

To answer the questions at the bottom: the next step is to start working 
on this and get folks excited about contributing.  There's plenty of 
time for process later, but filing a JEP or creating a project shouldn't 
be a barrier to innovating.


On 2/28/2018 10:33 PM, James Roper wrote:

Hi all,

We've put together a simple proposal for this. Please read the README for
an introduction to this proposal.

https://github.com/lightbend/reactive-streams-utils

Regards,

James

On 22 February 2018 at 11:47, James Roper  wrote:


Hi all,

This is an email to give people a heads up that we'd like to look at
creating an API, in the same vein as the JDK8 Streams API, for building
reactive streams (a la JDK9 juc.Flow). Our goals for this are:

* To fill a gap in the JDK where if a developer wants to do even the
simplest of things with a JDK9 juc.Flow, such as map or filter, they need
to bring in a third party library that implements that.
* To produce an API that can build Publishers, Subscribers, Processors,
and complete graphs, for the purposes of consuming APIs that use reactive
streams (for example, JDK9 Http Client).
* To produce an API that aligns closely with ju.stream.Stream, using it
for inspiration for naming, scope, general API shape, and other aspects.
The purpose of this goal is to ensure familiarity of Java developers with
the new API, and to limit the number of concepts Java developers need to
understand to do the different types of streaming offered by the JDK.
* To produce an API that can be implemented by multiple providers
(including an RI in the JDK itself), using the ServiceLoader mechanism to
provide and load a default implementation (while allowing custom
implementations to be manually provided). There are a lot of concerns that
each different streams implementation provides and implements, beyond
streaming, for example monitoring/tracing, concurrency modelling, buffering
strategies, performance aspects of the streams handling including fusing,
and context (eg thread local) propagation. This will allow libraries to use
and provide contracts based on this API without depending on a particular
implementation, and allows developers to select the implementation that
meets their needs.

Non goals:

* To produce a kitchen sink of utilities for working with reactive
streams. There already exist a number of reactive streams implementations
that seek to meet this goal (eg, Akka Streams, Reactor, RxJava), and once
you go past the basics (map, filter, collect), and start dealing with
things like fan in/out, cycles, restarting, etc, the different approaches
to solving this start to vary greatly. The JDK should provide enough to be
useful for typical every day streaming use cases, with developers being
able to select a third party library for anything more advanced.

We will update this list when we have something ready for public review.
This probably won't be far off. Our hope is that we can propose this as a
JEP.

Regards,

James

--
*James Roper*
*Senior Octonaut*

Lightbend  – Build reactive apps!
Twitter: @jroper 

Re: Java SE Language Changes

[Andrew Haley]

On 07/03/18 03:46, A Z wrote:
> Is there any route forward with these changes?

I believe not.  Java floating-point arithmetic is specified by IEEE-754.  If you
want something different, Java is not the language you are looking for.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: RFR 8196298 Add null Reader and Writer with latest changes

[Patrick Reinhart]

I applied those changes here:

http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.02

-Patrick


> Am 06.03.2018 um 23:12 schrieb Brian Burkhalter :
> 
> Yes, I think so and and also the parameter ‘csq' is allowed to be null so 
> Objects.requireNonNull(csq) should be removed at lines 100 and 107 as no NPE 
> is specified for these methods [1, 2].
> 
> Thanks,
> 
> Brian
> 
> [1] 
> https://download.java.net/java/jdk10/docs/api/java/io/Writer.html#append(java.lang.CharSequence)
> [2] 
> https://download.java.net/java/jdk10/docs/api/java/io/Writer.html#append(java.lang.CharSequence,int,int)
> 
> On Mar 6, 2018, at 11:49 AM, Bernd Eckenfels  wrote:
> 
>> Just a nit, Should append(CharSequence,int,int) also use checkFromIndexSize?
>