Oooh, interesting. While not exactly right some could probably be re-purposed as an RNG yes… Especially cryptographic hash functions seem interesting, but they are probably far to slow. Something that looks like a cryptographic hash function to someone who really sucks at cryptography is probably what I’m looking for. Also there are probably some things to gain from collisions being a non-issue and the output needed being extremely short.
I don’t actually know exactly what I need this for, it’s just somehting I for some reason tend to stumble upon repeatedly when I think about compsci things and has thus concluded would be generally useful. Procedural generation, either for games, art, or math experiments, probably constitutes most of it thou.
>>> import random
>>> def random_lookup(key):
random.seed(("Whatever", key))
return random.randint(0, 999)
>>> random_lookup(11)
885
>>> random_lookup((42, 115, 802))
481
>>> random_lookup((31, 42, 717))
805
>>> random_lookup("strings are good keys too")
564
>>> random_lookup(11)
885
>>> random_lookup("strings are good keys too")
564
… internally, he’s just using the hash of your input as a random seed, but then you can get random floats, etc.
I used something like that to get boundless fields of random temperatures, elevation and humidity, resulting in a tile-based world with mountains, oceans, swamps, forests etc. that you could scroll as far as you wanted to in any direction, and always get the same thing for a given position.
Ok, that’s pretty fast for python. Should be fast enough for anything with speed requirements that makes python a viable language in the first place. Unless I did the math wrong somewhere.
4000 per second is probably way to slow for any application I might use, and I don’t think I have quite the kind of wizardry needed to employ the graphics card for anything.
Not awfully—I haven’t counted but for a screenful of terrain tiles there can’t be more than a thousand calls, which could be a bit slow if you’re recalculating everything every frame, but is fast enough as soon as you cache your results, so that you only need to calculate new, undiscovered terrain.
If performance is really a problem, it’s always possible to rewrite the slow bits in C, using simpler algorithms than the Python hash function.
That sounds like a hash function, or are you looking for something else? (something faster?)
What applications do you have in mind? Procedural generation in games, or something else?
reads up on hash functions
Oooh, interesting. While not exactly right some could probably be re-purposed as an RNG yes… Especially cryptographic hash functions seem interesting, but they are probably far to slow. Something that looks like a cryptographic hash function to someone who really sucks at cryptography is probably what I’m looking for. Also there are probably some things to gain from collisions being a non-issue and the output needed being extremely short.
I don’t actually know exactly what I need this for, it’s just somehting I for some reason tend to stumble upon repeatedly when I think about compsci things and has thus concluded would be generally useful. Procedural generation, either for games, art, or math experiments, probably constitutes most of it thou.
In Python, you can do things like
… internally, he’s just using the hash of your input as a random seed, but then you can get random floats, etc.
I used something like that to get boundless fields of random temperatures, elevation and humidity, resulting in a tile-based world with mountains, oceans, swamps, forests etc. that you could scroll as far as you wanted to in any direction, and always get the same thing for a given position.
Nice trick, thanks, but isn’t it awfully slow?
How fast do you need it to be? My laptop can do SHA1 about 2^20 times with no noticeable delay.
Ok, that’s pretty fast for python. Should be fast enough for anything with speed requirements that makes python a viable language in the first place. Unless I did the math wrong somewhere.
Thanks.
Sorry, that’s not actually Python. I was minting a 20-bit Hashcash stamp.
Edit: In Python, I get 2^15 hashes in similar time.
Edit2: and if for some reason you need insane speed, I believe graphics cards can be made to perform hashing.
Edit3: with the specific code listed in the 4-parent, rather than using hashlib.sha1(), about 2^12. The point is that computers are fast.
4000 per second is probably way to slow for any application I might use, and I don’t think I have quite the kind of wizardry needed to employ the graphics card for anything.
I don’t think Pavitra was talking about seconds, but in “no noticeable delay”—on my laptop, in python, I get about 2^22 hashes per second.
Oh. Well then I don’t know but it’ll be worth trying if I ever need to do somehting like this in python.
Not awfully—I haven’t counted but for a screenful of terrain tiles there can’t be more than a thousand calls, which could be a bit slow if you’re recalculating everything every frame, but is fast enough as soon as you cache your results, so that you only need to calculate new, undiscovered terrain.
If performance is really a problem, it’s always possible to rewrite the slow bits in C, using simpler algorithms than the Python hash function.