Welcome! Please see the About page for a little more info on how this works.

+1 vote
in Java Interop by
retagged by

Check the below gist to see detailed results.

Note that using interop is ok for me,
I am in an operations research use case where time consumption of random value is important.

But I wonder why clojure should not propose a better version of rand-int.

I suspect (but I will check if needed) that the nextInt version may be more uniform (statistically closer from the theory).

PS: Duplicate from a question in slack, channel clojure.

2 Answers

+3 votes
selected by
Best answer

For absolute efficiency (or at least not leaving anything on the floor), having a specialized variant for rand-int makes sense to me. I think this was the simple implementation from clojure 1.0. It probably simplified having everything unified by the implicit global prng in Math/random. There have been complaints about lack of seedability with this approach over the years though; the common solution seems to define a dynvar with a random instance and delegate calls to it, although you incur lookup costs with the dynvar. You would have to introduce a dedicated Random instance for rand-int though (simple enough...just close over one).

Note that if you're really focused on performance, the PRNG from https://dsiutils.di.unimi.it/docs/it/unimi/dsi/util/XoRoShiRo128PlusRandom.html is about 2x faster than java.util.random on my machine, and there are more specialized techniques like https://dragan.rocks/articles/19/Billion-random-numbers-blink-eye-Clojure that go further (although those examples would need to be coerced to ints, and maybe wrapped with some streaming api, and also require pulling in additional dependencies).

0 votes