Date: Saturday, April 3, 2021 at 2:35 PM
To: Chris Dennis
Cc: core-libs-dev
Subject: Re: 8214761: Bug in parallel Kahan summation implementation
Hey Chris,
I don't know exactly what triggers removal of the "oca" and "oca-verify"
labels. The only OCA entry for Chris Denn
A gentle prod. Am I misunderstanding procedure here?
From: Chris Dennis
Date: Monday, March 22, 2021 at 2:28 PM
To: core-libs-dev
Subject: 8214761: Bug in parallel Kahan summation implementation
I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - but have
been stuck waiting
I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - but have
been stuck waiting on OCA signatory status to be confirmed. Did something get
lost in the shuffle or do I just need to be more patient.
Thanks,
Chris
dennis.0178d0f136e9, mixed mode,
sharing)
1.0 + 1.1102230246251565E-16
=> 1.0
DoubleStream.of(1.0, 1.1102230246251565E-16).sum()
=> 0.
That's the sum of two positive doubles returning a result smaller than one of
the two.
Apologies for the zeal,
Chris
On 8/27/20, 10:52 AM, &
Bump...
I've run in to this while running tests that check computation results against
the expected bounds of a Kahan summation. Any chance that this gets picked up
in the near future?
Thanks,
Chris
On 12/13/18, 6:16 PM, "core-libs-dev on behalf of Ivan Gerasimov"
wrote:
Gentle ping.
Hi All,
Apologies for dredging up an older mail thread. I lurk and follow along with
various JDK development threads and this 166 integration change jumped out at
me. I have to confess although I understood the intent of the change and the
explanation in the comments, like David I found it very
Is there a more suitable mailing list for this kind of core-libs spec related
enquiry to be directed at?
Thanks,
Chris
> On Oct 9, 2018, at 10:48 AM, Chris Dennis wrote:
>
> I’m attempting to clarify the meaning/intent of the language in the
> specification of the ide
.map(a -> (R) a)
.orElse(Stream.empty().collect(collector));
} else {
return streams.flatMap(identity()).collect(collector);
}
}
Thoughts, opinions?
Thanks,
Chris Dennis
Just to confirm this looks fine to me. From my point of view too much input
validation would seem a little odd given that the implementation does nothing
to protect itself from overflow in the first place.
> On Nov 1, 2017, at 1:21 PM, Paul Sandoz wrote:
>
>
>> On 31 Oct 2017, at 16:46, joe
we consider
the other collectors missing the unordered attirbute attribute to be a bug
then, and get it fixed for 10?
> On Nov 1, 2017, at 3:55 PM, Stuart Marks wrote:
>
> On 10/27/17 1:56 PM, Chris Dennis wrote:
>> I’m very confused about what was intended with the ‘UNORD
Collectors.toSet(), which although it is explicitly marked as
unordered seems like it really shouldn’t be.
Whats going on here? Which parts of all this are intended and which (if any)
are bugs?
Thanks in advance for any enlightenment,
Chris Dennis
P.S. Coincidentally the unordered toSet
internal state then
this still works.
> On Apr 12, 2017, at 12:27 PM, Peter Levart wrote:
>
>
>
> On 04/12/2017 04:41 PM, Peter Levart wrote:
>> On 04/11/2017 10:48 PM, Chris Dennis wrote:
>>> Color me confused… what would the javadoc on the parameter say? It could
gumentException.class, () -> new
DoubleSummaryStatistics(-1, 0, 0, 0));
+ expectThrows(IllegalArgumentException.class, () -> new
DoubleSummaryStatistics(1, 3, 2, 0));
}
}
> On Apr 11, 2017, at 4:48 PM, Chris Dennis wrote:
>
> Color me confused… what would the javadoc on
unt * max >= sum, count * min <= sum,
>> cannot be reliably enforced due to overflow i am inclined to not bother and
>> just document.
>>
>>
>> Note this is gonna be blocked from pushing until the new Compatibility and
>> Specification Review (CSR) proces
ent (in what I presume was an attachment) is
> missing. I believe the OpenJDK mailing list servers intentionally strip out
> attachments in all emails, which seems to be at odds with the advice given in
> http://openjdk.java.net/contribute/. (Either the contribution advice or the
&g
Hi Paul (et al)
Like all things API there are wrinkles here when it comes to implementing.
This patch isn’t final, there appears to be no existing test coverage for these
classes beyond testing the compensating summation used in the double
implementation, and I left off adding any until it was
I can do that. I’ve done this before a couple of times, so it should be
reasonably familiar. Will attempt to whip something up in the next couple of
days.
Thanks,
Chris
> On Apr 5, 2017, at 12:30 PM, Paul Sandoz wrote:
>
> Hi Chris,
>
> I logged this issue:
>
> https://bugs.openjdk.java.n
0/2017 03:14 PM, Chris Dennis wrote:
>> This is indeed nice… but I presume that we all agree that the best solution
>> here would be to allow instantiation of an IntSummaryStatistics object in a
>> specific state.
>
> Of course. I just couldn't resist the challenge of
This is indeed nice… but I presume that we all agree that the best solution
here would be to allow instantiation of an IntSummaryStatistics object in a
specific state.
> On Mar 29, 2017, at 2:43 PM, Peter Levart wrote:
>
>
>
> On 03/29/2017 06:06 PM, Chris Dennis wrote:
&g
Stream.summaryStatistics() is implemented as follows:
>
> public final IntSummaryStatistics summaryStatistics() {
> return collect(IntSummaryStatistics::new, IntSummaryStatistics::accept,
> IntSummaryStatistics::combine);
> }
>
> Paul.
>
>> Rémi
>&
which events are pushed is going to
hit this problem - a simple example would be any kind of calculation being
performed in advance of stream creation. Right now the lack of interface
decoupling here means I have no choice but to ‘brute-force’ all these
calculations.
Thanks,
Chris Dennis
that this is not
necessarily the class loader from which the file was actually loaded.”
This will obviously cause confusion for anyone using the ServiceLoader to load
singleton services who is not currently in total control of their classpath.
Dependencies that are both present and shaded would cause a problem for example.
Thanks,
Chris Dennis
22 matches
Mail list logo
