On Sun, Apr 3, 2011 at 2:35 AM, William Tanksley, Jr <wtanksle...@gmail.com> wrote: > I love this kind of thing. I'm surprised to hear that we're doing so > much work to get our random numbers; most roguelikes don't bother. > > I agree that we can do better; I think we should look for something > (1) faster and (2) with a smaller state. The period shouldn't matter, > since although we're generating a lot of numbers, we're doing so in a > context where actually USING the repeats will be completely > impossible. (For this reason, it's unfortunate that we're using a > fancy long-period generator, since it has all the wrong tradeoffs -- > slow, big state, and low-quality numbers.)
Let's not be too mean to MT, it works well enough for most purposes. I do, however, believe that the authors are flimflamming people with its absurd period. (NB. The Universe would die before you could exhaust MTs stream, even if you turned every atom into a transistor.) > I rather admire the first RNGs the author of that paper proposes; they > look to me like they meet all the requirements, and better yet they're > VERY short code. Owing to my distaste for global state, and desire to use these generators in a thread-safe manner, I've wrapped them up in a C++ lib (http://www.github.com/bhickey/librng/). > I don't know if I'd care to make things any more complicated than > that. Yes, we CAN throw in an encryption algorithm; but why? This > isn't rocket science. We should be resistant to attempts to discover the RNG state. I have no idea how someone managed to do it (I don't see anything in random.cc that would leak all 32-bits of an output), but I'm told it has been done. I haven't put any thought into the difficulty of determining the internal state of KISS (and its variants) from a series of emissions. As fun as it is to think otherwise, the security requirements for Crawl are less stringent than those for SSL. Whatever solution we go with should prioritize speed and simplicity without compromising the statistical behavior of the generator. If we end up modifying something, we should run it through a test battery before deploying it. > (BTW, in my youth I wrote the RNG that Biskup used for ADOM (he > tweaked it a little, and replaced the 'unsigned' variables with > 'signed' ones, which is why that one version came out where all the > rooms were dark and all the items were daggers). It was a simple RC4 > stream. If you want, I can do it again -- although I wouldn't bother > if I were making the decision. RC4 has very simple code and a simple > state, only 256 permuted bytes and 2 index bytes; but those RNGs are > far simpler.) Neat. I had thought about using RC4, but I agree that it's a poor choice. The state is simply too big! Brendan ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Crawl-ref-discuss mailing list Crawl-ref-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/crawl-ref-discuss
