>>> 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.
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.