On Sat, 4 May 2019 at 23:52, Alex Herbert <alex.d.herb...@gmail.com> wrote:
> > > > On 4 May 2019, at 22:34, Gilles Sadowski <gillese...@gmail.com> wrote: > > > > Hi. > > > > Le sam. 4 mai 2019 à 21:31, Alex Herbert <alex.d.herb...@gmail.com> a > écrit : > >> > >> > >> > >>> On 4 May 2019, at 14:46, Gilles Sadowski <gillese...@gmail.com> wrote: > >>> > >>> Hello. > >>> > >>> Le ven. 3 mai 2019 à 16:57, Alex Herbert <alex.d.herb...@gmail.com > <mailto:alex.d.herb...@gmail.com>> a écrit : > >>>> > >>>> Most of the samplers in the library have very small states that are > easy > >>>> to compute. Some have computations that are more expensive, such as > the > >>>> LargeMeanPoissonSampler or the DiscreteProbabilityCollectionSampler. > >>>> > >>>> However once the state is computed the only part of the state that > >>>> changes is the RNG. I would like to suggest a way to copy samplers as > >>>> something like: > >>>> > >>>> DiscreteSampler newInstance(UniformRandomProvider) > >>>> > >>>> The new instance would share all the private state of the first > sampler > >>>> except the RNG. This can be used for multi-threaded applications which > >>>> require a new sampler per thread but sample from the same > distribution. > >>>> > >>>> A particular case in point is the as yet not integrated > >>>> MarsagliaTsangWangSmallMeanPoissonSampler (see RNG-91 [1]) which has a > >>>> "large" state [2] that takes a "long" time [3] to compute but is > >>>> effectively immutable. This could be shared across instances saving > >>>> memory for parallel application. > >>>> > >>>> A copy instance would be almost zero set-up time and provide > opportunity > >>>> for caching of commonly used samplers. > >>> > >>> The goal is sharing (immutable) state so it seems that the semantics is > >>> not "copy". > >>> > >>> Isn't it a "factory" that we are after? E.g. something like: > >>> public final class CachedSamplingFactory { > >>> private static PoissonSamplerCache poisson = new > PoissonSamplerCache(); > >>> > >>> public PoissonSampler createPoissonSampler(UniformRandomProvider > >>> rng, double mean) { > >>> if (!poisson.isCached(mean)) { > >>> poisson.createCache(mean); // Initialize (requires > >>> synchronization) ... > >>> } > >>> return new PoissonSampler(poisson.getCache(mean), rng); // > >>> Construct using pre-built state. > >>> } > >>> } > >>> [It may be overkill, more work, and less performant…] > >> > >> But you need a factory for every class you want to share state for. And > the factory actually has to look in a cache. If you operate on an instance > then you get what you want. Another working version of the same sampler. It > would also be thread safe without synchronisation as long as the state is > immutable. The only mutable state is the passed in RNG. > > > > Agreed. It was what I meant by the last sentence. > > > >>> > >>> IIUC, you suggest to add "newInstance" in the "DiscreatSampler" > interface (?). > >> > >> I did think of extending DiscreteSampler with this functionality. Not > adding to the interface as it currently is ‘functional’ as it has only one > method. I think that should not change. Having thought about it a bit more > I like the idea of a new functional interface. Perhaps: > >> > >> interface DiscreteSamplerProvider { > >> DiscreteSampler create(UniformRandomProvider rng); > >> } > >> > >> Substitute ‘Provider’ for: > >> > >> - Generator > >> - Supplier (possible clash or alignment with Java 8 depending on the > way it is done) > >> - Factory (though the method is not static so I do not like this) > >> - etc > >> > >> So this then becomes a functional interface that can be used by > anything. However instances of a sampler would be expected to return a > sampler matching their own functionality. > >> > >> Note there are some samplers not implementing an interface that also > could benefit from this. Namely CollectionSampler and > DiscreteProbabilityCollectionSampler. So does this need a generic interface: > >> > >> Sampler<T> { > >> T sample(); > >> } > >> > >> To be complimented with: > >> > >> SamplerProvider<T> { > >> Sampler<T> create(UniformRandomProvider rng); > >> } > >> > >> So the library would require: > >> > >> SamplerProvider<T> > >> DiscreteSamplerProvider > >> ContinuousSamplerProvider > >> > >> Any sampler can choose to implement being a Provider. There are some > cases where it is mute. For example a ZigguratNormalizedGaussianSampler > just stores the rng in the constructor. However it could still be a > Provider just the method would only call the constructor. It would allow > writing a generic multi-threaded application that just uses e.g. a > DiscreteSamplerProvider to create samplers for each thread. You can then > drop in the actual implementation you require. For example you could swap > the type of PoissonSampler in your simulation by swapping the provider for > the Poisson distribution. > >> > >> How does that sound? > > > > Fine to have > > DiscreteSamplerProvider > > ContinuousSamplerProvider > > [Perhaps the "Supplier" suffix would be better to avoid confusion with > > "UniformRandomProvider".] > > > > At first sight, I don't think that the generic interface would have > > any actual use since, ultimately, the return value of "sample()" > > will be either "int" or "double" (no polymorphism). > > > > The generic interface is for the samplers that are typed for collections > and currently return a sample T, or those that return arrays. It would not > be for Integer or Double from the probability distribution samplers. Here > are what could use it: > > CombinationSampler implements Sampler<int[]> > PermutationSampler implements Sampler<int[]> > CollectionSampler implements Sampler<T> > DiscreteProbabilityCollectionSampler implements Sampler<T> > > All are in the package org.apache.commons.rng.sampling. > > Each could also implement SamplerSupplier<T>. > > The set-up cost for the CombinationSampler/PermutationSampler would not be > much different from the constructor and no state can be shared. No real > benefit here other than convenience. But the two CollectionSamplers could > shared the final collection that is created and stored from the constructor > input data. For the case of a large discrete probability collection sampler > this could be a noticeable memory footprint as it also stores the > cumulative distribution table. This would also save on the construction > cost by not having to recompute it. > > Alex > Any further thoughts on this? I think that Supplier is perhaps the wrong term. A Java 8 Supplier has a get() functional method with no parameters. These interfaces would require a UniformRandomProvider as the argument. However the Java 8 Function<T, R> apply method which is applicable here is is a poorer name. So: DiscreteSampler ContinuousSampler Sampler<T> and trying a few options out: DiscreteSamplerFactory createDiscreteSampler(UniformRandomProvider) ContinuousSamplerFactory createContinuousSampler(UniformRandomProvider) SamplerFactory<T> createSampler(UniformRandomProvider) vs. DiscreteSamplerFactory newDiscreteSampler(UniformRandomProvider) ContinuousSamplerFactory newContinuousSampler(UniformRandomProvider) SamplerFactory<T> newSampler(UniformRandomProvider) vs. DiscreteSamplerSupplier getDiscreteSampler(UniformRandomProvider) ContinuousSamplerSupplier getContinuousSampler(UniformRandomProvider) SamplerSupplier<T> getSampler(UniformRandomProvider) vs. DiscreteSamplerGenerator newDiscreteSampler(UniformRandomProvider) ContinuousSamplerGenerator newContinuousSampler(UniformRandomProvider) SamplerGenerator<T> newSampler(UniformRandomProvider) The 'create/new' nomenclature does convey that a new instance is expected, so I prefer that over get. I'm undecided on which is the most appropriate noun for the interface name. > > > > Gilles > > > >> > >> Alex > >> > >> > >> > >>> I'm a bit wary that this would compound two different functionalities: > >>> * data generator (method "sample"), > >>> * generator generator (method "newInstance"). > >>> [But I currently don't have an example where this would be a problem.] > >>> > >>> Regards, > >>> Gilles > >>> > >>>> Alex > >>>> > >>>> [1] https://issues.apache.org/jira/browse/RNG-91 < > https://issues.apache.org/jira/browse/RNG-91> > >>>> > >>>> [2] kB, or possibly MB, of tabulated data > >>>> > >>>> [3] Set-up cost for a Poisson sampler is in the order of 30 to 165 > times > >>>> as long as a SmallMeanPoissonSampler for a mean of 2 and 32. Note > >>>> however that construction still takes only 1.1 and 4.5 microseconds > for > >>>> the "long" time. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > >
