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
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
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 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
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.
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
On Sat, Aug 28, 2021 at 5:56 AM Stig Korsnes wrote:
> Thank you again Robert.
> I am using NamedTuple for mye keys, which also are keys in a dictionary.
> Each key will be unique (tuple on distinct int and enum), so I am thinking
> maybe the risk of producing duplicate hash is not present, but co
Thank you again Robert.
I am using NamedTuple for mye keys, which also are keys in a dictionary.
Each key will be unique (tuple on distinct int and enum), so I am thinking
maybe the risk of producing duplicate hash is not present, but could as
always be wrong :)
For positive ints i followed this ti
joblib is a library that uses clever caching of function call results to
make the development of certain kinds of data-heavy computational pipelines
easier. In order to derive the key to be used to check the cache, joblib
has to look at the arguments passed to the function, which may
involve usuall
Thank you Robert!
This scheme fits perfectly into what I`m trying to accomplish! :) The
"smooshing" of ints by supplying a list of ints had eluded me. Thank you
also for the pointer about built-in hash(). I would not be able to rely on
it anyways, because it does not return strictly positive ints w
On Thu, Aug 26, 2021 at 2:22 PM Stig Korsnes wrote:
> Hi,
> Is there a way to uniquely spawn child seeds?
> I`m doing monte carlo analysis, where I have n random processes, each with
> their own generator.
> All process models instantiate a generator with default_rng(). I.e
> ss=SeedSequence() cs
Hi,
Is there a way to uniquely spawn child seeds?
I`m doing monte carlo analysis, where I have n random processes, each with
their own generator.
All process models instantiate a generator with default_rng(). I.e
ss=SeedSequence() cs=ss.Spawn(n), and using cs[i] for process i. Now, the
problem I`m
12 matches
Mail list logo
