Re: cellfun and parcellfun

[Jaroslav Hajek]

On Fri, Jun 11, 2010 at 11:28 PM, David Bateman <address@hidden> wrote:
> Robert I A Patterson wrote:
>>>
>>>
>>
>> I understand the reasons, although it leads to quite awkward behaviour
>> from a Monte Carlo point of view. Imagine I run 8 sample paths using 8
>> processes via parcellfunc.  If I have already used some random numbers,
>> all 8 paths will be identical, but if this happens to be the first thing
>> I do when I start Octave I will get 8 different samples (provided each
>> process gets different data from /dev/urandom).  I wonder if some kind
>> of note in the parcellfun documentation might be appropriate:
>> "Note that each process will inherit a copy of the random number
>> generator state that existed before the call to parcellfun.  If that
>> state is uninitialised, each process will perform the default
>> initialisation of its random number generator separately.  In the latter
>> case it is possible, but not certain that each process will initialise
>> its random number generator differently."
>>
>
> This is why I suggested that a feature like rand("state", "reset") that
> reinitialized the state of the generator would be a good feature to have.
> Using this as the first call in each forked process would ensure that the
> state is different always in all forked processes. It should be relatively
> easy to do this except for the care needed with the fact that the randlib
> generators all use the same state and the mersenne twister based generators
> have separate states and so rand("state", "reset") should change only the
> uniform generators state, but rand("seed", "reset") should change all of
> them.
>

The problem with this approach is that you could longer save state to
get reproducible results. I made a different change instead: When
starting parcellfun, the parent process queries the state first; then
each forked process resets it, adjusting by its index.


> Something like the attached should do it. Anyone mind if I commit it?

This might be useful as is, so no objections.

-- 
RNDr. Jaroslav Hajek, PhD
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz