Is it really too much to ask for a visible grid? I get the rules of mining but sometimes it looks like you are clicking 2 spots away diagonally but you waste a click clicking 1 spot away from the original click. Some clarity would be nice
Is it really too much to ask for a visible grid? I get the rules of mining but sometimes it looks like you are clicking 2 spots away diagonally but you waste a click clicking 1 spot away from the original click. Some clarity would be nice
They again changed the grid... Looks like it's the original grid again...
This is great! I'm working through some optimal mining strategies and statistics myself and this is a great foundation to work with.
A couple things -
In the example of picking a starting location that is Very Close, I think where the general principle is shown the strategy results in an average of 1/8 higher number of turns than the optimal strategy. Consider the following, where X represents the starting pick, numbers represent turn number, and V or N represent Very Close or Near respectively in previous turns.
For example, VNV4 represents the 4th move where the initiating move X was the Very Close creating the scenario, followed by 1 which was also Very Close; followed by V2 which was Near; followed by followed by VN3 which was Very Close, followed by VNV4 where success is certain.Code:V2 VV3 N2 1 X NV3 VN3 VNV4 NN3
As it is written in your write up, N2 and NV3 and switched, and NN3 becomes NVN4, resulting in an extra move 1/8 of the time.
By my reading of the fully mapped strategy, I think you follow the pattern I present. However because that strategy only works for the first fragment and the general principal needs to be followed on following fragments, I think it's worth having the optimal strategy clearly defined.
Also, the average number of fragments per bomb (per entry to the mine?) given as 2.55 appears to be:
However because successive fragments will already have additional information in the form of an average of 4.7 bombed locations where the fragment will not be found, would it make sense to say that 2.55 is a lower bound to the average? I haven't worked through the math of successive fragments to see whether the additional information really helps or if they somehow disrupt the optimal algorithm in some unforeseen way, but just wanted to check the assumption about the simple average given above.Code:Average Fragments = Total Bombs / Average Bombs per Fragment
Hope I've understood this all correctly! Am I missing anything? Thanks again!
Cheers,
Z
Last edited by zinj; 04-12-15 at 06:24 PM.
Okay, I finally put this game on my tablet, which has a far bigger screen than my phone. I figured I'd finally be able to use this guide effectively due to the larger size. However, after following the guide twice, I realized that the active area in the mine is smaller than the one used in this guide. The grid doesn't match up, so the guide is useless. Great. The grid is bigger by one section around the entire edge.
Could we please change the first post to state that this feature is available to all users? This must have changed at some point after the post was written, but Android users definitely do have the mining feature now.
My mining simulator and search algorithm appears to be working. After an initial set of results that seemed soundly coded but improved more than expected on what I had arrived at through manual optimization, I took care of a couple bugs and I?m getting results that match the average of 4.7 bombs per first fragment described in the original post.
The search algorithm is based on identifying the bomb location with the greatest number of potential fragment locations it can search and the greatest variance of the distances it can identify (Near, Very Near, or Too Far). This will give the greatest amount of information to shape next moves. I arrived at this through the manual optimization of cases where some positions were already bombed. It generalized what I observed in the first-fragment clean mine as well.
The benefit of the approach is that it will work for new fragments in a bombed mine mine where a map will break down after the first fragment. It?s an open question whether there are possible improvements on the algorithm for already-bombed mines. For example, identifying the optimal approach when there are not enough bombs for a complete search. I haven?t had a chance to give thought to whether searching spaces with less available locations (bombed areas) offers any advantage over areas with more available locations (less bombed areas). More bombed areas will more quickly narrow down to a successful target, but have a lower chance of holding the target in the first place. I think this may come down to some machine learning approaches. Initial attempts to choose bombing sites based on reduced number of possible locations when bomb supply dwindles only decreased average number of hits.
Without making any adjustments for a small number of bombs, the algorithm that matches the fresh mine statistics in the original post find an average of 2.263 +/- 0.010 fragments in each mine. This based on 20,000 iterations.
I'm coding this in R and would be willing to share the scripts or perhaps package into a library if others are interested. I have a version that directs my bombing rather than simulating it, and I notice an increase in rounds with 3 successes while using it.
Cheers,
Z
Last edited by zinj; 04-20-15 at 01:02 AM.
Minor edit. Previous variance calculations included the 0 distance finding the target on the move in question. However this would not be a random variable when choosing the next move, which is what the search optimization is ultimately concerned with. Removing the zero distance location from the variance calculation increased the average number of fragments per mining session from 2.26 to 2.29 based on 10,000 iterations.
Last edited by zinj; 04-23-15 at 02:45 PM.
Hi, just came to know about yr strategy. Hvn't gone thru the entire thing as yet as I'm unable to open any of the images. Any suggestions on how to view the images. Many thx in advance