Hello.
> On 11/04/2019 13:22, Gilles Sadowski wrote:
> >>> [...]
> >> 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",
>
> The state it is a linear sum. So can be jumped very easily.
>
> y = mx + c
>
> c is the current Weyl state, m the number of transitions and x the Weyl
> increment. So we can make SplitMix Jumpable. The maximum jump length is
> 2^64 which will wrap the state.
>
> > hence the
> > "Weyl way" to ensure no-overlap, with high probability (why "weak
> > assurance"?)
> I used the term "weak assurance" as opposed to "concrete assurance". The
> wording used by the JDK is "with very high probability, the set of
> values collectively generated by the two objects has the same
> statistical properties as if the same quantity of values were generated
> by a single object". It is a bit of semantics.
>
> >
> > 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.]
>
> The likelihood of overlap is 1/[the number of different Weyl sequences].
> This is around 2^-63. So it is small. However the base implementation
> for SplitMix uses a specific Weyl sequence increment based on the golden
> ratio. I do not know the original of this. For example is it better that
> any other irrational number converted to an integer, e.g. pi, Euler's
> number (e), sqrt(2)? The irrational number comes from the origin of the
> Weyl sequence which is based on irrationals. But there may be no reason
> that the golden ratio was chosen rather than any other source irrational.
Does the non-overlap weak assurance take into account the fact that
there are no irrational numbers in a truncated representation (like the
one stored in a computer)?
Isn't it why those "internal" numbers are carefully selected (like in
"TwoCmres"), because they generate
