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 advantage

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 subpackage

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 Nov

Re: How to extract matches from (\d+[hms])+ ?

iteration disappear (but you may need to check whether the original string was empty). But maybe that takes all the fun out of it. --Guy Steele On Sep 25, 2014, at 12:51 AM, Wang Weijun wrote: > Hi Sherman > > I want to match a time duration like "1h20m30s" and "2

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

now really 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 str

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 wrote: > It would be inappropriate/incorrect to app

Re: Impact of code difference in Collection#contains() worth improving?

On Aug 29, 2014, at 7:33 PM, John Rose wrote: > . . . > Changing source code on based on the difference between 0 and -1 is almost as > pointless as removing whitespace and comments . . . Well said, John! But I cannot resist recalling that one of the earliest pieces of software in the impleme

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 wrote: > > Am 01.04.2014 11:28, schrieb Bruce Chapman: >> Slightly preceding Ulf's coin proposal by a few h

Re: Implicit 'this' return for void methods

On Mar 26, 2014, at 4:17 AM, Ulf Zibis 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 the code of void me

Re: Draft JEP on enhanced volatiles

On Feb 7, 2014, at 3:44 PM, Brian Goetz 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 that provides the dou

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

On Sep 16, 2013, at 1:02 PM, Doug Lea 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. This m

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

On Sep 16, 2013, at 10:50 AM, Doug Lea wrote: >try { >Enumeration ifcs = >NetworkInterface.getNetworkInterfaces(); >boolean retry = false; // retry once if getHardwareAddress is null >while (ifcs.hasMoreElements()) { >Ne

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, 20

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

rity-detection algorithm. --Guy On Aug 28, 2013, at 6:54 PM, Alan Eliasen wrote: > On 08/28/2013 04:47 PM, Guy Steele wrote: >> *ahem* Y'know, Common Lisp had a good solution for >> printing self-referential structures (by a user-extensible print >> function) back i

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

ny case, I think everyone is now agreed on "the right thing" for going forward. --Guy On Aug 28, 2013, at 9:48 PM, Joseph Darcy 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 >

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 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 toString() > be

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 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. Excellent! Nice piece o

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 ad

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

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

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

On Aug 19, 2013, at 4:20 PM, Mike Duigou wrote: > > On Aug 19 2013, at 13:12 , Guy Steele wrote: > >> >> On Aug 19, 2013, at 3:17 PM, Mike Duigou wrote: >> >>> - I find disallowing the zero bounds and empty ranges slightly annoying. It >>&g

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

On Aug 19, 2013, at 3:17 PM, Mike Duigou 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 externally special case f

Re: class SplittableRandom

On Jul 19, 2013, at 1:05 AM, Kasper Nielsen 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 spinning up a couple of

Re: class SplittableRandom

On Jul 16, 2013, at 2:57 PM, Guy Steele 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 a

Re: class SplittableRandom

On Jul 15, 2013, at 4:13 PM, Martin Buchholz wrote: > > On Mon, Jul 15, 2013 at 9:59 AM, Martin Buchholz wrote: >> >> 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 >> efficient since the wraparound

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 wrote: > > On Jul 15 2013, at 16:11 , Doug Lea wrote: > >> On 07/15/13 12:59, Martin Buchholz wrote: >>> If

Re: class SplittableRandom

On Jul 16, 2013, at 3:07 AM, Martin Buchholz 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(); } > or more cons

Re: class SplittableRandom

On Jul 15, 2013, at 4:13 PM, Martin Buchholz 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 */ >public Spli