"10s update - this time using 35m detection radius and better math."

#PokemonGO: Alright, the last post blew up, and unfortunately people were distracted by the fact that I used 70m as the radius of the detection range, and it's in fact the diameter. This threw all of my math off and you should really really see these new updated values. I was also far more rigorous about my calculations, and found actual percentage of missed area instead of simply finding the distance to the left or right where finding was guaranteed and using that. I'll put the results first, and then the math below for those who care to investigate.If you know for sure exactly what the detection radius is, please share in the comments! I've heard everything from 35m to 100m. I used 35m for these calculations.For a walker who is traveling at 1 m/s at a 5s update rate:New area covered per second: 69.9 m2Pokemon missed within detection radius of route: 0.09%Walker at 1 m/s at 10s update rate:New area covered per second: 69.9 m2 (same travel speed)Pokemon missed within detection radius: 0.34%Pokemon seen relative to 5s walker: 99.55%Biker at 5.5m/s and 5s update rate:New area covered per second: 374.8 m2Pokemon missed within detection radius of route: 2.64%Pokemon seen relative to 5s walker: 522.61%Biker at 5.5m/s and 10s update rate:New area covered per second: 340.5 m2Pokemon missed within detection radius of route: 11.55%Pokemon seen relative to 5s walker: 431.26%TL;DR - Bikers got nerfed by missing an additional 1 in 11 pokemon...but they still see random pokemon along their route at over 4x the rate of a walker (assuming pokemon spawn along your route in random fashion).For the curious, here's my math. To calculate the area "overlapped" or scanned in both the current ping and the previous one, I used the following formula taken from this website.=((2r2 )ACOS(d/(2r))-d/2(4*r2 - d2 )0.5)Armed with that information, I used PI()*r2 -[overlap] to calculate the amount of "new" area covered per update with variable velocity and update interval. d was calculated with (velocity * update frequency).Percentage of "missed" pokemon I fudged, but very very slightly. I did not account for the area behind your first scan that you miss on the edges of the corners of your detection range, since we all know that our detection range isn't square. However, I did fudge by counting the detection range in that square area ahead of your final scan against your detection efficiency or "missed pokemon." This means that the reality is slightly better than predicted for all categories, and that fewer are missed. Since this is a systemic error that is counted equally in all cases and vanishes to zero as the length of your walk increases, I decided to be ok with it.I calculated it by taking that "new" area covered per update divided by 2rd. 2r is the width of your detection range at its widest times 2 (to the right and left). Multiplying it by the distance forward you traveled gives you the maximum area you could possibly scan. This compares the new area traveled forward to the area you're actually scanning per update. It returns a percentage that is about 11% at 50m traveled per update, and vanishingly small at anything below 10m per update. The actual formula is here:=[New Detection Area Per Update]/(2r*d)The good news is that my earlier math was only off by 3% in its final assessment of biking at 10s v. walking at 5s. However, I got a bit lucky because I made one big assumption and one big mistake that mostly offset one another. Here's the bottom line:Biking at 10s updates gives you over 4x the number of random pokemon at the cost of missing 1 in 11 pokemon that the walker would have seen along the first quarter of your route.You can either see 11 out of 11 pokemon, or see 47/54 pokemon. Your call. via /r/TheSilphRoad http://ift.tt/2axSzwm