Re: New candidate JEP: 356: Enhanced Pseudo-Random Number Generators

> On Jun 24, 2019, at 3:46 AM, Kasper Nielsen wrote: > > Hi Guy, > > This looks really good, a couple of quick questions and comments. > > 1) > I think a natural home for this would be java.math? Good suggestion; but others have suggested making a new package java.util.random. One

Re: New candidate JEP: 356: Enhanced Pseudo-Random Number Generators

Sure, that would be a completely reasonable move. Who should make that decision? —Guy > On Jun 21, 2019, at 2:36 PM, mark.reinh...@oracle.com wrote: > > By my count this JEP would add ten new public types to the java.util > package. Is it time to consider creating a java.util.random

Re: Need help with OpenJDK sandbox branch creation

> On May 23, 2019, at 2:23 PM, Kevin Rushforth > wrote: > > You need to be a 'jdk' Project Committer [1] in order to push to any repo in > the jdk Project, including the sandbox. > > -- Kevin > > [1] https://openjdk.java.net/census#jdk Yep, that’ll do it. Thanks!

Need help with OpenJDK sandbox branch creation

t: 56598:6a68d15c5569 branch: JDK-8193209-branch tag: tip parent: 56596:65b0b63d7f14 user: Guy Steele date:Wed May 22 16:15:51 2019 -0400 summary: Initial changes for JDK-8193209 ——— Please, does anyone have any clues for me? —Guy

Draft JEP: Enhanced pseudo-random number generators

Please check out a new draft JEP https://bugs.openjdk.java.net/browse/JDK-8193209 that proposes new interface types and implementations for pseudo-random number generators. —Guy

Re: Please Review Draft JEP: More memory-efficient internal representation for Strings

As far as it goes, it looks good to me. I do note that so far it has no mention of the academic literature that has already explored this or related problems, and I hope that part of the activity would be to survey and summarize this literature before making implementation decisions. —Guy On

Re: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

Good point, but counterpoint: it might be acceptable to have modified the string buffer in situations where throwing an exception would always cause the string buffer to become inaccessible. —Guy On Sep 8, 2014, at 1:30 PM, Jonathan Gibbons jonathan.gibb...@oracle.com wrote: It would be

Re: Optimization 2.0 for composing strings - Was: Replace concat String to append in StringBuilder parameters

getting pretty specific. -- Jon On 09/08/2014 10:41 AM, Guy Steele wrote: Good point, but counterpoint: it might be acceptable to have modified the string buffer in situations where throwing an exception would always cause the string buffer to become inaccessible. —Guy On Sep 8

Re: Implicit 'this' return for void methods

Then it sounds as if the three of us, at least, are very much in agreement about what is the appropriate scope for such a “naked dot” feature. —Guy On Apr 1, 2014, at 7:26 AM, Ulf Zibis ulf.zi...@cosoco.de wrote: Am 01.04.2014 11:28, schrieb Bruce Chapman: Slightly preceding Ulf's coin

Re: Implicit 'this' return for void methods

On Mar 26, 2014, at 4:17 AM, Ulf Zibis ulf.zi...@cosoco.de wrote: See also: . . . http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/001180.html This last one has a specific proposal, which is simple and quite nice. The important idea is that we don’t actually make any change to

Re: Draft JEP on enhanced volatiles

On Feb 7, 2014, at 3:44 PM, Brian Goetz brian.go...@oracle.com wrote: . . . As a limitation, I'd call out that its not obvious how this would scale to DCAS. Just off the top of my head: (var1, var2).doubleCompareAndSet(e1, e2, x1, x2) thus providing access to a VolatileIntInt interface

Re: RFR 8024253: ThreadLocal random can use SecureRandom for the initial seed

On Sep 16, 2013, at 10:50 AM, Doug Lea d...@cs.oswego.edu wrote: try { EnumerationNetworkInterface ifcs = NetworkInterface.getNetworkInterfaces(); boolean retry = false; // retry once if getHardwareAddress is null while

Re: RFR 8024253: ThreadLocal random can use SecureRandom for the initial seed

On Sep 16, 2013, at 1:02 PM, Doug Lea d...@cs.oswego.edu wrote: On 09/16/2013 11:39 AM, Chris Hegarty wrote: On some platforms, Windows, tunneling interfaces report a very bad mac address, e.g. 00-00-00-00-00-00-00-E0. I wonder if it is worth skipping all isVirtual() nifs? Good idea.

Re: RFR: 8023339 : (xs) Rename Collection.removeIf(Predicate) to removeAll(Predicate)

Let me point out that the xxxIf form of name for this idea (removing elements of a list that satisfy a predicate, or otherwise operating on the elements of a list that satisfy a predicate) has a history tracing back to the year 1979. That's more than a third of a century. --Guy On Sep 5,

Re: RFR: 7057785 : (xs) Add note to hashCode() that support for self referential is optional

On Aug 28, 2013, at 6:13 PM, Mike Duigou mike.dui...@oracle.com wrote: On Aug 28 2013, at 11:48 , Martin Buchholz wrote: This isn't just about hashCode - I'm not sure why you are singling it out. What about toString? A reasonable point. The bug reports are just about as common for

Re: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1

think everyone is now agreed on the right thing for going forward. --Guy On Aug 28, 2013, at 9:48 PM, Joseph Darcy joe.da...@oracle.com wrote: Hello, On 8/23/2013 1:36 PM, Guy Steele wrote: The specification of java.lang.Math.round in the first edition of the Java Language Specification

Re: RFR: 7057785 : (xs) Add note to hashCode() that support for self referential is optional

, 2013, at 6:54 PM, Alan Eliasen elia...@mindspring.com wrote: On 08/28/2013 04:47 PM, Guy Steele wrote: oldfogey *ahem* Y'know, Common Lisp had a good solution for printing self-referential structures (by a user-extensible print function) back in 1984. It leaned on the solution that had been

Re: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1

On Aug 24, 2013, at 3:02 PM, Jeff Hain jeffh...@rocketmail.com wrote: Dmitry Nadezhin wrote: Nevertheless, I send this variant now in hope that it may be useful. Great! It's much faster than what I proposed, cleaner (only integers), and according to my tests it behaves the same.

Re: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1

on as a (perhaps unfortunately worded) shorthand for the original specification. --Guy Steele On Aug 23, 2013, at 4:24 PM, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote: The specification of java.lang.Math.round() says * Returns the closest {@code int} to the argument, with ties * rounding up

Re: Java 8 RFR 8010430: Math.round has surprising behavior for odd values of ulp 1

There seem to be two distinct issues here: (1) As originally specified in the first edition of JLS, java.lang.Math.round sometimes accepts an argument that is equal to a mathematical integer and returns a value that is another (larger) mathematical integer because IEEE rounding occurs in the

Re: RFR 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom

On Aug 19, 2013, at 3:17 PM, Mike Duigou mike.dui...@oracle.com wrote: - documentation of bound should mention that it is exclusive rather than relying on the return documentation. Agreed. - I find disallowing the zero bounds and empty ranges slightly annoying. It requires me to

Re: RFR 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom

On Aug 19, 2013, at 4:20 PM, Mike Duigou mike.dui...@oracle.com wrote: On Aug 19 2013, at 13:12 , Guy Steele wrote: On Aug 19, 2013, at 3:17 PM, Mike Duigou mike.dui...@oracle.com wrote: - I find disallowing the zero bounds and empty ranges slightly annoying. It requires me

Re: class SplittableRandom

On Jul 19, 2013, at 1:05 AM, Kasper Nielsen kaspe...@gmail.com wrote: Thanks so much for your feedback! Your points are well taken. Telling people that your random source passes the die-hard test but at the same time only using the current time as the seed is just pure evil. Imagine

Re: class SplittableRandom

On Jul 16, 2013, at 3:07 AM, Martin Buchholz marti...@google.com wrote: Read Appleby and Stafford ... Hmmm mix32 has almost the same job as mix64 - have all the bits in the seed affect all the bits in the output, so the obvious implementation is mix32() { return (int) mix64(); }

Re: class SplittableRandom

Maybe SplittableRandom should be an interface, and the current implementation called, say, SplittableRandom64 (for its 64-bit seed). --Guy On Jul 16, 2013, at 12:55 PM, Mike Duigou mike.dui...@oracle.com wrote: On Jul 15 2013, at 16:11 , Doug Lea wrote: On 07/15/13 12:59, Martin Buchholz

Re: class SplittableRandom

On Jul 15, 2013, at 4:13 PM, Martin Buchholz marti...@google.com wrote: On Mon, Jul 15, 2013 at 9:59 AM, Martin Buchholz marti...@google.comwrote: Also, if gamma is much less than 2^64 (say 2^56; that number of gammas should be enough for anybody), then the above will be a little more

Re: class SplittableRandom

On Jul 16, 2013, at 2:57 PM, Guy Steele guy.ste...@oracle.com wrote: . . . So here's the punchline: this change makes my Monte Carlo calculation of pi run over 19% faster! Hard to believe. It's certainly avoiding most of the hard work in addGammaModGeorge, and perhaps also making branch

Re: class SplittableRandom

On Jul 15, 2013, at 4:13 PM, Martin Buchholz marti...@google.com wrote: I'll be your loyal adversary today, trying to break SplittableRandom. Thanks so much! This is exactly the sort of skepticism we need. Let's make it easier by providing a low-level constructor: /** Testing */