Detailed Retrodictive Ranking Violation Analysis

September 12, 2017

By waelder - Own work, CC BY 2.5, https://commons.wikimedia.org/w/index.php?curid=1962578 When I first started programming the notion of writing maintainable code was defined by "leaving a large enough gap between consecutive line numbers that no one would ever have to re-punch the whole deck of cards." With the advent of text-editors and digital source code the emphasis correctly shifted to "making it easy for the poor bloke who has to fix or enhance your code to understand what the heck it does."

In my first real programming assignment (per force, in a "maintenance" role) I learned that the only reasons to maintain a program are:

  1. It doesn't meet the specifications it was supposed to (i.e. it is broken.)
  2. The specifications for the current functionality are changed so the progam must be altered to meet those the original programmer was not prescient enough to anticipate.
  3. The specifications are changed to require entirely new functionality.
The program that I'd been given to maintain was being bombarded by nearly hourly requirement changes and was an extreme example of the what the heck? review of source code, so I told my boss two days before it was to go into production I was trashing the existing source and re-writing it. To his credit, he just rolled his eyes and did not tell me not to.

I replaced the hugely complicated large program with a simple one that used an algorithm that took into account that the input specifications were going to change frequently - instead of having to modify hundreds of lines of (badly-written) assembly languange when another "special case" was added at the last minute, you only had to add it to one of the "special case tables." Which leads to …

4. There's a better way to meet the same specifications.
Here "better" usually means "more efficient" but "making it more maintainable" is sometimes reason enough to rewrite a program using only its specifications.

So when I decided to add a feature to the Weighted Retrodictive Ranking Violation report instead of tweaking the program I started from scratch with the additional feature in mind. As often happens, the support for the new feature made it easy to add several more that had not occurred to me. The core of the routine turned out to be so much more efficient than its predecessor the program runs in less time even with the extra features.

The WRRV page now includes the details behind the numbers.

Rankings in Weighted Retrodictive Ranking Violation Order
This is the original report. Rows are teams in ascending Bucklin Majority rank order, columns are rankings in ascending average (over teams) order, and the row/column intersection is the rank assigned to the row-team by the column-ranking. Team-names link to the list of rankings for each rank for the team.

Teams' Weighted Violations
With the row and column orders the same, the row/column intersections are the sum of weighted violations accumulated by the ranking due to games involving the team. Column 1 (WRRV) is the average WRRV (over all rankings) for each team. Team-names link to their schedules, and ranking-names link to a list of the games for which the ranking has a retrodictive ranking violation.

Teams' Ranking Violations
Again the order of rows and columns is the same, but the row/column intersection is just the count of retrodictive ranking violations, and column 1 (RRV) is the average RRV over rankings.

Games with Ranking Violations
Lists every game with any ranking violation by any ranking, sorted by cumulative weighted violations due to the games (summed over rankings.) It lists every ranking for which the game is a violation.

Ranking Violations by Rating
For each rating, list the games that represent retrodictive ranking violations in chronological order. The rating name in the header links to the rating's official site (the same site that the College Football Ranking Composite references.) The WRRV contribution by the game to the rating's WRRV is shown in the first column labeled Weight.
The second report is the new feature I started with. The rest were just easy to do. I threw in the last two because having them saves me having to go look at the schedules to explain the ratings' WRRV values. Sort of like when on a quiz there's the phrase "show your work."

© Copyright 2017, Paul Kislanko
Football Home


By waelder - Own work, CC BY 2.5, Link