Thanks again Robert!
Got rid of dict(state).
Not sure I followed you completely on the test case. The "calculator" i am
writing , will for the specific use case depend on ~200-1000 processes.
Each process object will return say 1m floats when its method scenario is
called. If I am not mistaken, th
And big kudos for building AND shepherding :)
søn. 29. aug. 2021 kl. 12:56 skrev Stig Korsnes :
> Thanks again Robert!
> Got rid of dict(state).
>
> Not sure I followed you completely on the test case. The "calculator" i am
> writing , will for the specific use case depend on ~200-1000 processes.
On Sun, Aug 29, 2021 at 6:58 AM Stig Korsnes wrote:
> Thanks again Robert!
> Got rid of dict(state).
>
> Not sure I followed you completely on the test case.
>
In the code that you showed, you were pulling out and storing the `.state`
dict and then punching that back into a single `Generator` in
I am indeed making ~200-1000 generator instances.As many as I have
processes. Each process is an instance of a component class , which has a
generator. Every time i ask this process for 1m numbers, i need the same 1m
numbers. I could instead make a new generator with same seed every time I
ask for
On Sun, Aug 29, 2021 at 10:55 AM Stig Korsnes wrote:
> I am indeed making ~200-1000 generator instances.As many as I have
> processes. Each process is an instance of a component class , which has a
> generator. Every time i ask this process for 1m numbers, i need the same 1m
> numbers. I could in
Agreed, I already have a flag on the class to toggle fixed "state". Could
just set self._rng instead of its state. Will check it out.
Must say, had not in my wildest dreams expected such help on any given
Sunday. Have a great day and week, sir.
Best,
Stig
søn. 29. aug. 2021, 18:29 skrev Robert Ke
