Thanks for all of the feedback so far, it's been helpful. Mars0i, keeping an RNG for each thing that needs to have an independent random state seems like a good idea for a fallback, and the suggestion of using a different RNG is a good one. It's also helpful to know other people have dealt with similar problems.
Laurens, Using a PRF actually sounds very close to ideal for what I was looking for. If I can convert a map (or record) to a reproducible seed, and have that be independant from other random checks, that's pretty close to exactly what I wanted. Looks like if I want to use libraries like clojure.data.generators or bigml.sampling I'd need to amend the random generators to replace calls to the Mersenne Twister function or (def ^:dynamic *rnd* (java.util.Random. 42)). As long as I can figure out how to install caesium/libsodium on Windows, it should theoretically be possible to substitute the PRF there, though I'd have to rewrite some functions to replace the calls to .nextDouble, .nextFloat, et cetera. I'm assuming that just passing the hash as a seed to MT wouldn't work. If I can get away with something like (binding *rnd* (random-number-generator (blake2b [seed thing-to-hash]))) using it becomes trivial. But I'm just knowledgeable enough to know I don't know enough to be confident of that. Granted, the current application is an art project that will be just fine with some non-random randomness, so the tolerance for error is fairly high. Speed isn't a major concern yet: implementation before optimization. I'm currently using a ridiculously naive rules system, which works just fine for my grand total of (so far) three rules. Filtering the rules is probably going to be the bottleneck long before the randomness in the conflict resolution. On Friday, October 31, 2014 11:15:44 AM UTC-4, Laurens Van Houtven wrote: > > Hi, > > > I too, am super interested in games in Clojure. My other background is > cryptography, so I break out the crypto. I would say that you don’t really > want a PRG, but you might want a PRF instead. (If that doesn’t mean > anything to you, don’t worry, read on.) > > My favorite cryptographic hash function, BLAKE2, has a number of cool > features that might help. If you have some description of the thing that > you want and a random seed, you can produce a number from which you can > then go on and generate whatever you want. This answers your “sub-seed” > question: blake2(master_seed, “room 1”) and blake2(master_seed, “room 2”) > will be completely different values. However, you can compute > blake2(master_seed, “room 1”) at any later point, and it will still be the > same value. This makes all of the problems of sharing, ordering… go away. > No more state :) > > This does mean passing a seed around in your game state, but it seems > evident to me that your seed is indeed a fundamental property of your game > state, so I don’t think that’s a bad thing. > > While BLAKE2 is of course significantly stronger than what you need for a > game, it is ridiculously fast [1]. In case you’re worried about speed (you > most likely shouldn’t be), SipHash is still significantly stronger than > what you need (nearly cryptographic strength), but is competitive in speed > with non-cryptographic hash functions like CityHash, Murmur2/3.... > > Neither BLAKE2 nor SipHash nor other PRFs typically come with the > randomness utility features you would typically want, like random > selection, weighted random selection, random variable according to a > distribution… Hopefully those things are available in a way that lets you > separate the concern of “generate n pseudorandom bits” and “use those bits > to produce a value”. Of course, other PRNG algorithms like MT also don’t > solve this problem: they just give you some random-looking bytes, just like > BLAKE2/SipHash :) > > BLAKE2 is exposed with a nice Clojure API through my caesium library. I > don’t know of any easily available SipHash implementations, but I can’t > imagine it’s very hard to get it running. There’s a Java implementation, > and various Lisp implementations that shouldn’t be terribly hard to port to > Clojure. > > [1]: https://blake2.net/ > [2]: https://131002.net/siphash/ > > > hth > lvh > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
