Thanks Johannes,

what I meant with the 'time' keyword is to offer the user the possibility to obtain pseudo random behavior, but the usual behavior would be to use fixed seed.

I will think about the feasibility of implementing your suggestion.

Best

Michel

On 07/19/2012 09:27 PM, Johannes Pfeifer wrote:

Dear Michel,

I agree with you that setting the seed consistently makes sense. Hence, we should reseed before a controlled sequence is clearly needed by the user.

But a rather difficult issue involves the behavior of stochastic solvers like csminwel or cmaes or mode_compute=6. With your procedure their behavior would probably not be consistent across runs anymore. I know we discussed this some time ago, because the mode should be (almost) the same regardless of the seed in use. But then we decided that reproducibility across runs is an important feature for users. Setting the seed according to the system time might prevent this. Hence, I would prefer to split up the options_.dynare_seed to account for the different functions of the seed. One function would clearly be the stochastic simulation case you describe.

Cheers,

Johannes

-- Johannes Pfeifer Haußerstr. 29 72076 Tübingen Tel.: +49-(0)7071-6396184 Mobil.: +49-(0)170-6936820 Germany

-----Ursprüngliche Nachricht----- Von: dev-bounces@dynare.org [mailto:dev-bounces@dynare.org] Im Auftrag von Michel Juillard Gesendet: Donnerstag, 19. Juli 2012 18:57 An: List for Dynare developers Betreff: [DynareDev] setting seed in Dynare

I was asked why, while setting the seed, the shocks were not the same in a simulation based on 1st order or on 3rd order.

It took me a while to realize that condest() that is used in dyn_first_order_solver.m is calling rand()

I think that we need to change the way we control the random generator. I suggest that set_dynare_seed only set the value of options_.dynare_seed and that before each function where users can expect to control a random sequence we use options_.dynare_seed to reseed the random generator. We could use keyword 'time' for dynare_seed so that we reseed with system time

What do you think?

Best

Michel

---

Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev

---

Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev

"Johannes Pfeifer" jpfeifer@gmx.de writes:

My point rather was that by resetting the seed for e.g. stoch_simul and then running estimation, we also reset the seed used in csminwel1. Hence, the order of calling functions may still matter as in the case you described unless we always reset the seed each time we generate random numbers.

What you describe is already happening with the current implementation of the seed. The change suggested by Michel won't make it worse.

The issue is less pressing since I removed calls to condest() in dyn_first_order_solver(). It was the only function that used it.

Best

Michel

On 07/30/2012 03:58 PM, Sébastien Villemot wrote:

Michel Juillardmichel.juillard@mjui.fr writes:

...

I was asked why, while setting the seed, the shocks were not the same in a simulation based on 1st order or on 3rd order.

It took me a while to realize that condest() that is used in dyn_first_order_solver.m is calling rand()

I think that we need to change the way we control the random generator. I suggest that set_dynare_seed only set the value of options_.dynare_seed and that before each function where users can expect to control a random sequence we use options_.dynare_seed to reseed the random generator. We could use keyword 'time' for dynare_seed so that we reseed with system time

I am fine with both the idea of reseeding at relevant places, and to add the possibility of seeding with time.

---

Dev mailing list Dev@dynare.org https://www.dynare.org/cgi-bin/mailman/listinfo/dev