separate PRNG seed for generated quantities
Bob Carpenter
The point to do this would be in the Stan 3 refactor
if people think it's worthwhile --- it'll change behavior for
existing programs unless we allow an option to use the
same PRNG stream to both, but I don't think that's a big
deal. It would need to be plumbed through the all of
the interfaces to allow the second seed to be specified.
Or maybe we could do something like generate separate
seeds internally rather than supplying two seeds.
The point to make an issue is when there's a well-defined
behavior. I don't think we're quite there yet.
- Bob
> On Dec 14, 2015, at 11:27 AM, Sebastian Weber <sdw....@gmail.com> wrote:
>
> Hi!
>
> I was wondering if Stan uses a single rng stream for the inference part (anything which is not generated quantities) and the prediction part (the generated quantities part). What makes people often confused is that they change something which only affects the generated quantities part, but this then changes the exact numerical values of the inference part - which happens if a single random number generator stream is used for inference and prediction.
>
> It would be great to use distinct random number streams for inference and prediction such that same model and same data always give the same inference, regardless of the prediction being made. Is that desirable for other users and would it be doable in Stan? If both can be answered with yes, then I am happy to file a feature request...
Sebastian Weber
The behavior users seem to expect is:
i) same data, prior and likelihood => same inference
ii) same inference => same prediction
However, the current design leads to different inference if during prediction a random number is used. Given that this is a big effort to implement, I suggest that users are given the following possibility:
1. Do the inference without executing the generated block => i) holds
2. Let users feed the posterior into stan and selectively run only the generated block => ii) holds as well
As far as I recall, Stan 3 is supposed to enable such flexibility, right?
Sebastian
On Monday, December 14, 2015 at 7:51:10 PM UTC+1, Bob Carpenter wrote:
> [moved to stan-dev]
>
> The point to do this would be in the Stan 3 refactor
> if people think it's worthwhile --- it'll change behavior for
> existing programs unless we allow an option to use the
> same PRNG stream to both, but I don't think that's a big
> deal. It would need to be plumbed through the all of
> the interfaces to allow the second seed to be specified.
> Or maybe we could do something like generate separate
> seeds internally rather than supplying two seeds.
>
> The point to make an issue is when there's a well-defined
> behavior. I don't think we're quite there yet.
>
> - Bob
>
>
> > On Dec 14, 2015, at 11:27 AM, Sebastian Weber
> >
Bob Carpenter
any time soon. We have a lot more traction getting people
to help with new algorithms than we do with infrastructure
improvements like this.
- Bob
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.