> > [...] > > Not adding a dedicated method would mean everyone has to do this: > > JumpableUniformRandomProvider rng = (JumpableUniformRandomProvider) > RandomSource.create(…) > > But adding a mirror methods: > > JumpableUniformRandomProvider RandomSource::createJumpable(…) > LongJumpableUniformRandomProvider RandomSource::createLongJumpable(…) > > Does seem to add clutter to RandomSource. If we leave it out for now it can > be added in the future.
+1 (for leaving out). > Is there scope for needing the Jumpable to be detected through the API? E.g. > add: > > boolean RandomSource::isJumpable(RandomSource) > > We would just need to maintain an EnumSet for Jumpable and likewise for > LongJumpable. Again more clutter to the RandomSource interface but perhaps > less so than a mirror create method that would throw IllegalArgumentException > for any RandomSource specified that is not Jumpable. +1 (for leaving out for now). > > > [...] > >> > >> I was hoping to avoid creating a duplicate class. But actually that > >> would be fine and easier for testing. The implementation is trivial anyway. > > > > Why duplicate? > > IIUC, shouldn't the existing "core" class define an additional constructor > > that accepts the "K" argument. Then the current "SPLIT_MIX_64" > > would use the default increment. > > [Same as with "TWO_CMRES" and "TWO_CMRES_SELECT", no?.] > > OK. That was where I should have gone to start with. I’ll do that. > > > > >> I've just finished an initial implementation of the MSWS RNG that uses a > >> self-generated Weyl sequence. It works. So the idea for this can be > >> applied to SPLIT_MIX_64_K by using the same Weyl sequence generation in > >> both. Perhaps moving the code to create the Weyl sequence increment to > >> NumberFactory. > > > > +1 > > OK. So I created a Jira ticket for the SPLIT_MIX_64_K. I’m not sure when I’ll > get around to doing this though. It seems less important than other tasks. It > may even be redundant if the only reason is to increase the state space for > the generator. Each generator would still only have a period of 2^64. You can > just create a lot of them with a weak assurance they will not overlap and > that the uniformity is statistically the same. Since there are of the order > of 2^63 variants we are not going to be able to test this and would have to > rely on the theory behind it. > > If we add Jumpable to SplitMix with jumps of 2^32 and 2^48 then you can > create either 2^32 rngs with no overlap for the first 2^32 output numbers or > 2^16 rngs that can each be jumped 2^16 times with no overlap for the first > 2^32 output numbers. That is a lot for a small parallel situation and does > have the assurance of no overlap. Any parallel usage where longer sequences > are expected to be used can use one of the XorShiRo generators. I'm a bit lost here. I thought that "SplitMix64" did not provide "jump", hence the "Weyl way" to ensure no-overlap, with high probability (why "weak assurance"?) Anyways, I agree that SPLIT_MIX_64_K is low priority, but especially if we cannot ensure that the added flexibility does not come with unsuspected drawbacks (?). [IIRC, the article about "TwoCmres" reported experiments for choosing the (hard-coded) values that do produce good sequences.] Gilles --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
