Le jeu. 18 avr. 2019 à 21:53, Alex Herbert <alex.d.herb...@gmail.com> a écrit :
>
>
>
> > 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.
Thanks.
>
> 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?
You read my mind. ;-)
What would be the uses of "short" jumps (i.e. having small
non-overlapping sequences
from many instances, rather than a longer one from a single instance)?
IIUC, the hard-coded jump sizes in existing implementations seem a compromise,
based on the number of potentially concurrent threads, or independent
simulations.
Increasing that number does not seem necessary for the mid-term.
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
