Le dim. 28 avr. 2019 à 17:02, Alex Herbert <alex.d.herb...@gmail.com> a écrit :
>
>
>
> > On 28 Apr 2019, at 00:59, Bernd Eckenfels <e...@zusammenkunft.net> wrote:
> >
> > Hello,
> >
> > Just a question, I am unclear on the terminology, is „jump“ (did I miss the
> > discussion leading toot?) something invented here? It sounds to me like
> > this is a generator where the state can be cloned and it is „seekable“. It
> > probably makes sense to have those two dimensions separated anyway.
>
> Hi Bernd, thanks for the input.
>
> This thread started with the definition:
> Jump:
>
> To create a new instance of the generator that is deterministically based on
> the state of the current instance but advanced a set number of iterations.
>
>
> However it is not required to create a new instance at the same time as
> jumping. You are correct in that this is two functionalities:
>
> 1. Jump forward in the sequence
> 2. Copy
>
> However the two are coupled. Having jump on its own is useless (why move
> forward in the sequence without using it?). So a copy needs to be created
> somewhere before/after the jump.
>
> The idea of a jump is to create a series of the generator at different points
> in the state. The generators can be used for parallel computations and will
> be ensured to not overlap in their output sequence for number of outputs
> skipped by the jump length.
>
> FYI. The generators that support this have jump sizes of 2^64, 96, 128, 192,
> 256 and 512. So this is a lot of output sequence to jump.
>
> Copy on its own works but for what purpose? If you want a second generator at
> the moment you just create a new one (with a different seed). Duplicate
> copies of generators is prone to potential pitfalls where simulations are not
> as random as you intend. For a special use case where you wish to run
> multiple simulations with the same generator you can use the Restorable
> interface to save the state of one and re-create it in other instances.
>
> The current thread came to the choice of:
>
> >>> So the options are (in all cases returning the copy):
> >>>
> >>> 1. createAndJumpCopy
> >>> 2. copyAndJumpParent
> >>> 3. jumpParentAndCopy
> >>> 4. jump and copy separately
>
> Jump and copy separately was ruled out to discourage misuse of copy.
>
> The current suggestion is 1. Create a copy and jump that ahead. The current
> instance is not affected.
>
> I now consider this to be weaker for a variety of use cases than 2. This
> copies the current state for use and then jumps the parent ahead. So this
> alters the state of the parent generator.
>
> Note that all other methods of a generator alter its state. So having jump
> alter its state is reasonable.
>
> The most flexible API is to separate jump and copy into two methods. We can
> still support helper functions that take in a Jumpable generator and create a
> jump series of generators for parallel work. Separating jump and copy allows
> the functionality to be used in a larger number of ways than any other
> interface that attempts to combine jump and copy.
>
> I am fine with having separate jump and copy. If so the copy method, being
> part of the Jumpable interface, will be functionally coupled with the jump
> method and should be described in Javadoc with the intended purpose to use it
> to copy the parent state either before or after a jump into a child generator.
>
> As a precursor this API is very flexible:
>
> JumpableUniformRandomProvider extends UniformRandomProvider {
> /** Jump and return same instance. */
> JumpableUniformRandomProvider jump();
> /** Copy the instance. */
> JumpableUniformRandomProvider copy();
> }
>
> Returning the same instance in jump() allows method chaining such as either:
>
> rng.jump().copy();
> rng.copy().jump();
>
> This potential pitfall is that a user may do this:
>
> UniformRandomProvider rng1 = rng.copy().jump();
> UniformRandomProvider rng2 = rng.copy().jump();
>
> Where rng1 and 2 will be the same, 1 jump ahead of the parent state. Or:
>
> UniformRandomProvider rng1 = rng.jump();
> UniformRandomProvider rng2 = rng.jump();
>
> Where rng, rng1 and rng2 are the same instance all 2 jumps ahead of the start
> point.
>
> I think our purpose is to provide an API for the generators that can jump and
> that is not too restrictive given the use cases we have so far thought up.
> There may be other ideas of use cases that cannot be done with the coupled
> functionality of:
>
> JumpableUniformRandomProvider extends UniformRandomProvider {
> /** Copy the instance, then jump ahead. Return the copy of the previous
> state. */
> JumpableUniformRandomProvider jump();
> }
>
> JumpableUniformRandomProvider extends UniformRandomProvider {
> /** Copy the instance, then jump the copy ahead. Return the copy. The
> current instance is not affected. */
> JumpableUniformRandomProvider jump();
> }
>
> So the split functions without allowing method chaining:
>
> JumpableUniformRandomProvider extends UniformRandomProvider {
> /** Jump the current instance ahead. */
> void jump();
> /** Copy the instance. This is intended to be used either before or after
> a call to jump()
> * to create a series of generators. */
> JumpableUniformRandomProvider copy();
> }
As you indicated above, there is no advantage in having separate
"jump()" and "copy()",
as counter-intuitive it may look at first sight.
Regards,
Gilles
>
> WDYT?
>
> Alex
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
