Use numpy to generate random map

[smearle]

More than 2x avg. speed of legacy gen_random_map. (I noticed that trials with higher change_percentages were much faster than those with lower ones.)

[amidos2006]

That function return a 3D matrix and not a 2D?

[amidos2006]

Also when I tested it the matrix is a 3D where all the cells have the value of the length of probability dictionary

[amidos2006]

I am going to replace the function with that: random.choice(list(prob.keys()),size=(height,width),p=list(prob.values())).astype(np.uint8)

[smearle]

Ah, my apologies, I should have tested properly last night. I've fixed the broken method for posterity. But that one-liner looks great!

[amidos2006]

No problem, I always try to test code before adding it :) I will close that pull request :)

[smearle]

Yes me too. Last night I got caught up testing the speed of the function, and failed to check it worked again.

Speaking of speed, I notice that the new one-liner, beautiful as it is, is not as fast as what I was suggesting here. My uglier function is over 2x as fast, it seems. You can test this yourself by checking out this branch and running python3 gen_map_test.py. (And the function produces the required map this time!) I think speed is key, given our task, so I'm going to reopen the pull request.

[amidos2006]

I don't think that is much of difference

gen_random_map_oneline avg: 4.972288608551025e-05
gen_random_map avg: 4.87968921661377e-05

I modified the test to make sure it is fair :)

prob = {0:0.2, 1:0.2, 2:0.1, 3:0.5}

[smearle]

Weird, this is what I get:

gen_random_map_oneline avg: 7.11437463760376e-05  
gen_random_map avg: 2.2778701782226564e-05

[amidos2006]

that what I get now

gen_random_map_oneline avg: 4.7023987770080567e-05
gen_random_map avg: 5.614511966705322e-05

I think it is noise and different machines and it is tiny difference that the error is high based on ur machine

[smearle]

Strange, maybe it's a hardware difference? I am consistently getting numbers close to the ones I reported above.

[amidos2006]

mine on multiple runs, I get similar to the ones I post where the one-liner is slightly better on avg but usually the same speed

[amidos2006]

I might later speed up everything by trying to eliminate the transformation between numpy and string array and back. It was done to make sure that the prob doesn't care about numbers and define everything in form of string. I am experimenting with several solution while maintaining the same philosophy :)

[smearle]

Very strange that we're getting such different results! For me, uglier function is always over 2x as fast, as above. I just wonder why exactly! Might play around and see if I can replicate your results.

Ooh it sounds like we might be able to gain a lot of speed by eliminating the conversion to a string! Wiil keep in mind.

[amidos2006]

I don't think it is strange because the 2x is on a very tiny scale that depends on the machine you are trying to run the code on with different operating systems which cause a small difference on the backend of python 3 and numpy

[smearle]

So you're saying that my 'slice-based' version is more sensitive to changes in hardware/software, compared to your 'one-liner,' which is more flexible because it's built into numpy? Makes sense.