Chapbook

[mnaz]

I need to get more "serious" about photography when I retire (soon). Every picture I've taken so far has been simple point-and-shoot, no advanced settings or adjustments, but it's amazing how well some of them have turned out.

[sasha]

Nice try, but...

The Birch Hill WMA where I spend so much of my time lies in a flood-control watershed spanning parts of Royalston, Winchendon, & Templeton MA. Primary access is along old roadways left over from construction of the dam. A few legacy roads also remain open to vehicular traffic, but most are gated, reserved for hikers, equestrians, & cyclists; and a few ungroomed footpaths (possibly unauthorized) quietly sneak off into the bush from the marked trails. One of my favorites of these runs alongside an unnamed feeder of the Millers River, between one of the coffer dams and the river itself. On a recent tramp I noticed signs that at one time it may have been an access road, and found myself pondering its evolution to a barely-visible vestige of one.

I've tramped along many an old dirt road sporting a mohawk of grass running down the middle, and seen how many ways these roads can deteriorate over time: seasonal flooding, sporadic storm runoff, relentlessly encroaching vegetation... whatever. The wheel tracks don't always erode equally, so hikers would naturally tend to favor the one more passable, eventually giving Nature permission to devour the other. I began wondering if the process could be simulated on a computer.

I imagined someone heading out on such a road along one track or the other. If the road were still in pristine condition, it probably made little difference to him which one to follow - he choice could be made with a coin toss. To keep the model manageable, I imposed the condition that once the choice was made, it remained in effect for the rest of the hike - no lane-hopping allowed. But I also left open the possibility of future enhancement allowing one to walk down the middle following neither. (Start simple, add complexity later.)

If the coin is fair, there's a 50/50 chance of taking either track; but that doesn't mean that exactly 50 out of 100 hikers will go one way, and 50 the other. Since each coin toss is random, small deviations are to be expected. An outcome of, say, 53 heads (left) and 47 tails (right) out of 100 is just as likely (and much less remarkable) than exactly 50 of each.

So let's say that of the 1st 100 hikers, 53 took the left track, 47 took the right. This additional left-side traffic would pack the earth down a little more than on the right, keeping it slightly less prone to erosion, a little clearer of debris, a little less weedy. Conversely, the other side would receive slightly less benefit from traffic, rendering it slightly less desirable to walk - possibly enough so to skew the outcome of the coin toss. Based on the actions of the first 100 hikers, the next hundred might be tossing an unfair coin whose odds are 53/47 favoring the left. Each coin toss is still random - but the expectation is no longer the same number of heads as tails. In this example, we'd now expect slightly more heads, meaning more hikers following (in this example) the left track, furthering the degradation of the right.

What would this look like over the long haul?

To find out, I wrote a QB64 program hack to simulate it. * (Sidebar)

First, I set up house, defining and initializing parameters like the number of hikers per year the trail hosts (NHIKERS), and the probabilities of choosing the left track (PLEFT) vs. the right (PRIGHT)- both 0.5 at the outset. Then onto the meat of the program.

One by one, each hiker tosses the coin** , and I keep a running tab on how many go to the left (NLEFT) and how many go to the right (NRIGHT). As expected, roughly half of the first group went one way and about half went the other - but the key word here is "roughly". Even with 50/50 odds, a few more went one way than the other - so I let this slight imbalance redefine the probabilities for the next batch of hikers to base their choices on. The coin is no longer fair*** . This process repeats until one or the other of the two probabilities has dropped to zero, meaning no one in the group just processed chose to go that way.

I ran dozens of such trials, and the results are almost what I'd expected - almost. This graph is pretty typical - it clearly shows a growing aversion to one side - the left in this case - implying a growing preference for the other (the right). It wanders hither & thither from 50/50, gradually tending towards zero, at which point we can assume that Nature has completely reclaimed it.


Typical evolution over time of the odds of taking the left-hand track
 

 


But this one trial took over 300 cycles through the loop to do so! I'd set the group size to 1000 hoping to speed things along - yet If we interpret this as 1000 hikers per year, it took 300+ years for the left track to vanish. This was also typical of the other trials I ran - one trial ended after less than a hundred "years", another took over a thousand. If this 300-year example represented the access road whose ghost I'd walked that day, it must have been closed to wheeled traffic in the early 1700s, and seen over 30 hikers each day since. Though the program seems to be working just as desired, the results don't seem realistic. The problem must lie with the basic assumptions - the model itself. Something's missing. The model must be incomplete - or wrong..

It occurred to me that basing the probabilities only on the actions of the most recent year's activity might be incorrect - it seems to ignore the cumulative effect of years prior. So instead of resetting the traffic counts to zero at the beginning of each year, I kept accumulating them. The probabilities were then recalculated based on ALL prior traffic, not just the most recent year's worth. This only made the situation worse - there was no significant change to the coin! The odds bounced around, but never drifted far from their original settings of 50/50. The effects of wear & tear seemed to have been lost.


What happens to P(left) if I assume last year's hikers affect next year's outcome...
 

 

And there it stands. I'm not sure what to make of this. It leaves me in the uncomfortable situation of either accepting results of a model I know is wrong because they support my hypothesis, or those I don't believe from a model I think is closer to reality.

So I guess there's little left to do but follow a third option. All computer models are only as good as the assumptions on which they're built, so I guess all I can really conclude from this is that my model is too simplistic, a blunt instrument incapable of capturing reality's nuances. (Whether or not computer-generated randoms are really random is another matter, which I suspect only tries to deflect the blame from where it really lies.) Undoubtedly, foot traffic plays a role in trail degradation - as does grooming, weather, land stewardship... and the Grande Dame of them all, Entropy. It would have been nice to find corroboration of my guess, but Entropy has too many foot soldiers, too many tentacles to capture in a few dozen lines of QB64 code. Nice try, but the 2nd Law of Thermodynamics rules here. I haven't broken it, but I've been issued a warning.



--- P R O G R A M M I N G S I D E B A R S ---

* - QB64 is the great-great grandchild of the venerable GW-BASIC so many of my generation learned in high school. Unlike its ancestor, it's a compiled language, so the code is portable, and it's compatible with 64-bit processors. (I think it translates the source code into C++ to generate the executable.) It's easier to use than other languages I've programmed in - FORTRAN, COBOL, DYL260, Excel, and VB - it's surprisingly powerful, and it's FREE. The compiler's error messages can be a little cryptic - and I get plenty of them - but that's what Anglo-Saxon invective is for.

** - For the coin toss, I use the language's inherent random number function, RND(), which returns a random value between 0 and 1. If this value is less than one-half for the fair coin, I call it heads; otherwise it's tails. That dividing line changes to PLEFT (or PRIGHT) for the unfair coins.

*** - PLEFT = NLEFT / NHIKERS); and PRIGHT = NRIGHT / NHIKERS. Note that this is the same as 1-PLEFT, but I didn't calculate it this way (which would have eliminated the need to calculate NRIGHT), but I was leaving room for the possibility of later adding a 3rd option, NEITHER; but I never pursued that. Given how things turned out, that's probably for the better.