> On 18 Apr 2019, at 14:12, Gilles Sadowski <gillese...@gmail.com> wrote:
>
> Hello Alex.
>
>>>> [...]
>>
>> OK so this results in:
>>
>> /**
>> * Some summary.
>> */
>> public interface JumpableUniformRandomProvider extends
>> UniformRandomProvider {
>> /**
>> * Creates a copy of the UniformRandomProvider and advances the
>> state of the copy.
>> * The state of the current instance is not altered. The state of
>> the copy will be
>> * advanced an equivalent of {@code n} sequential calls to a method
>> that updates the
>> * state of the provider.
>> *
>> * @return the copy with an advanced state
>> */
>> JumpableUniformRandomProvider jump();
>> }
>>
>
> +1
> [Clean and lean: and no side-effects to explain...]
>
>>
>> This can be documented in an implementation as:
>>
>> public class MyJumpingRNG implements JumpableUniformRandomProvider {
>> /**
>> * {@inheritDoc}
>> *
>> * <p>The jump size {@code n} is the equivalent of {@code 2^64}
>> calls to
>> * {@link UniformRandomProvider#nextLong() nextLong()}.
>> */
>> @Override
>> public JumpableUniformRandomProvider jump() {
>> // TODO Auto-generated method stub
>> return null;
>> }
>> }
>
> +1
>
>>
>> Do we add a second interface for LongJumpableUniformRandomProvider?
>
> Sure, if the functionality is provided by some of the algorithms implemented
> in [RNG].
> But let's have the two functionalities in separate commits.
>
>>
>>>> So the options are (in all cases returning the copy):
>>>>
>>>> 1. createAndJumpCopy
>>>> 2. copyAndJumpParent
>>>> 3. jumpParentAndCopy
>>>> 4. jump and copy separately
>>>>
>>>> 1. Your preferred option. A copy of the state is made. The state is
>>>> advanced in the copy and returned. But when called repeatedly it will get
>>>> the same generator and code must be organised appropriately.
>>> We could provide a convenience method in "RandomSource":
>>>
>>> public UniformRandomProvider[] jump(int n,
>>> JumpableUniformRandomProvider parent) {
>>> final UniformRandomProvider[] rngs = new UniformRandomProvider[n];
>>> UniformRandomProvider tmp = parent;
>>> for (int i = 0; i < n; i++) {
>>> rngs[i] = restrict(tmp);
>>> tmp = tmp.jump();
>>> }
>>> return rngs;
>>> }
>>
>> +1. Remove the need for the user to repeat boiler plate code.
>>
>> Same sort of idea of longJump() too.
>
> +1
>
>>>> It is not actually possible to jump forward a single instance. Only
>>>> children are advanced.
>>> A feature: There is only one way to alter the state of an instance
>>> (i.e. a call to "next()").
>> OK.
>
> Great. :-)
>
> Gilles
This sounds like a resolution. I will put the ideas into a Jira ticket for
Jumpable.
I am a bit busy at the moment with other mini-projects (updates to nextInt(int)
being the main one, Poisson samplers (again) being another leading to a family
of log normal based distributions that may be supported using cumulative
probability look-up tables) but will hope to get this done soon. The actual
implementation should be quite easy.
Here’s one for you to think about on the subject of Jumpable. What about
support for the generators that can be advanced by a user specified increment?
For example the SplitMix algorithm is based on a sequence and so can be
advanced from 1 to 2^64-1 steps. It does seem strange to support this (if we
add jumpable to SplitMix) using only one specific jump distance. A Skippable
can do this:
SkippableURP {
public SkippableURP skip(long steps);
// or
public SkippableURP skipPower2(long power);
}
Too much?
>
>>>
>>>> [...]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
