Repeating an anecdote from our internal mailing list, since it's relevant to the weight loss question Jake Hofman brought up. (Oh, ha, and I hadn't even noticed till now that Jake is a prime example of the claim below about physicists!)
This is why physicists are better programmers than computer scientists are. Math FTW!
The amount of grief and future debugging we just saved ourselves by spending 20 minutes drawing graphs and writing equations on paper: kinda staggering.
Here's the answer to pessimistic presumptive reports: r - yaw*lnw
[lnw = lane width, yaw = +1 if good side of road is up, -1 if down, r = daily rate of the YBR]
That works for ALL graph types, including Do More where PPR doesn't even make sense (it comes out to zero as the PPR, which we'll special-case to say if PPR==0 then suppress it altogether).
In the case of PPRs for Do Less, r - yaw*lnw = r-(-1)r = 2r, which is how we implemented it originally.
Squee! I sure like math!
I was doing Project Euler problems the other day and thinking how preposterously far removed it was (writing little programs to solve those contrived math problems) from day-to-day getting actual shit done on real web apps. But this reminds me that it's surprisingly relevant.
Aaron Parecki chimes in: "in very specific cases."
Me again: But it's more often than you'd think, is the point. Like we could easily have just plowed forward writing code to make the right things happen in all the various cases without it ever occurring to us that there was an elegant mathy generalization that could replace all that code with an equation.
PS: Here's the 4 pages of pictures and equations that would've all been reams of code we'd have to maintain if we hadn't stepped back and did the math and turned it into "r - yaw*lnw":
PPS: And of course once you stare at "r - yaw*lnw" for a minute it all becomes perfectly obvious: the PPR follows the YBR from one day to the next (the "r" part) but then pulls back by one lane width in the bad (as in bad side of the road) direction.