On Sat, Feb 6, 2021 at 5:27 AM <camel-...@protonmail.com> wrote: > Well, I can tell you why it needs to be backward compatible! I use random > numbers fairly frequently, and to unit test them I set a specific seed and > then make sure I get the same answers. > > Hmm, I guess that makes sense. I tried to adjust my algorithms to do the > same thing with the same bit's as the original one, but I couldn't get it > to work. > > Have you benchmarked it using the generator interface? The structure of > this as a no monolithic generator makes it a good deal slower than > generating in straight C (with everything inline). While I'm not sure a > factor of 2 is enough to justify a change (for me 10x, 1.2x is not but I > don't know where the cutoff is). > > > I originally benchmarked my implementation against a bunch of other ones > in c (because I was developing a c library > https://github.com/camel-cdr/cauldron/blob/main/cauldron/random.h#L1928). > But I did run the built-in benchmark: ./runtests.py --bench > bench_random.RNG.time_normal_zig and the results are: > > new old > PCG64 589±3μs 1.06±0.03ms > MT19937 985±4μs 1.44±0.01ms > Philox 981±30μs 1.39±0.01ms > SFC64 508±4μs 900±4μs > numpy 2.99±0.06ms 2.98±0.01ms # no change for /dev/urandom > > > I'm not yet 100% certain about the implementations, but I attached a diff > of my current progress. > > You can actually get rid of the loop entirely and implement the exponential function directly by using an exponential bound on the bottom ziggurat block ends. It just requires a slight change in the block boundaries.
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
