One solution to OMNY's math problem
Here's one way to implement fare capping
In a prior post, I attempted to divine how OMNY determines the 7-day window for doing fare capping. There just doesn't seem to be an easy way to do the math, if we take their promotional copy seriously, or even semi-seriously.
To recap, for commuters using the OMNY card, they should only see charges top out at $34 during a seven-day period, no matter how many rides were taken. For a ride to be free, it must be ride #13 or higher inside some 7-day counting window. But it's not clear, given a sequence of prior taps, which tap is the first tap of the currently active 7-day window?
I can't find further details on the OMNY website, though. The key issue with the official description is that the "first tap" is hard to nail down.
Given a series of taps, let's imagine allowing each tap to initiate its own 7-day window. The only windows that should concern us are those that overlap with the present time (shown in blue below).
But as you can see in the diagram, we expect multiple such windows to include the present moment. The count of prior rides in each window is different, and so is the sequence number of the next ride! This is why our heads explode if we try to process their imprecise description.
***
There is a way around this mess. Instead of counting forwards, we count backwards.
Imagine a series of ride times associated with a commuter. That's the dataset I'm working with. The first thing I do is to drop most of this history; I only care about the rides that occurred within the last seven days.
To make things concrete, it's Monday 9 am sharp, and a commuter is tapping. Taking a 7-day backward window, I pull out this commuter's entire sequence of rides from last Monday 9:01 am up to and including 9 am. My goal is to determine if this next ride (at 9 am) should be free.
If the number of rides in that counting window is 13 or more, then this ride, i.e. the 13th ride in a 7-day period, should be free. If it's 12 or fewer, this ride will be charged.
Now, I will roll this window forward every time this commuter taps again. When the commuter rides again after work, say at 6 pm on Monday, I shift forward the counting window, to start at 6:01 pm last Monday ending at 6 pm today.
How does the number of rides change in the counting window relative to the morning? The count decreases by the number of rides that happened from 9:01 am to 6 pm the previous Monday, as this time segment drops out of the counting window. Simultaneously, the count increases by the number of rides that happened from 9:01 am to 6 pm this Monday.
The change in the ride count is the net of those two values. If more rides are added than dropped, the ride count goes up; conversely, the count decreases.
If the commuter does not leave the office during the work day, then there should be exactly one ride in the decrement window (occurring precisely at 6 pm the previous Monday), while there will be a single ride in the increment window, occurring at 6 pm today. The net change in the count is zero.
We still can't tell if the 6 pm ride today should be charged because we are missing information. We have to know how many rides were recorded in the prior counting window from 9:01 am previous Monday to 9 am this Monday. Let's say there were 13, meaning that the last ride, that is to say, the ride at 9 am today, should have been a free ride.
Free rides don't contribute to the fare cap. So, the increment window contains one ride, but zero paid rides. The net change in the count is -1. This commuter is now one ride shy of getting another free ride. Thus, the next ride will be charged.
***
This implementation of the 7-day fare capping does not square with the promotional language. For one thing, the "first tap" does not matter at all. We are counting backwards from the current time, not counting forwards from some "first tap".
In addition, each new tap refreshes the seven-day counting window. There is no such thing as "the rest of the 7-day period" because the window is continuously shifting forwards. Therefore, this is not what OMNY said they implemented, if we trust the promotional language.
My algorithm can be described simply and precisely: the next ride is free if it's paid ride #13 or higher within the last seven days. However, it's still not easily audited by commuters. You typically can't recall how many rides you've taken in the prior seven days, down to the minute. (It's even worse I imagine for those tapping their credit cards, as the OMNY transactions are dispersed among your other charges.)
You can be someone who just trusts authority. In that case, they can do whatever they want, because you aren't checking. You'd also praise whatever it is they do as effortless and convenient.
In reality, you've outsourced the auditing task to other commuters who care, or watchdogs. Your trust derives from people like me. What I'm finding out is there isn't even enough information out there to verify their implementation.
