> On 19 Apr 2019, at 15:30, Gilles Sadowski <gillese...@gmail.com> wrote: > > Le jeu. 18 avr. 2019 à 21:53, Alex Herbert <alex.d.herb...@gmail.com > <mailto: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
I could not think of one. Just wanted to raise the suggestion. It would not be supported for many generators anyway (currently only SplitMix, maybe more in the future). > 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 > <mailto:dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > <mailto:dev-h...@commons.apache.org>
