Resolving Loops in GridMap

A simple example of a loop is as follows: team A defeats team B, team B defeats team C, and team C defeats team A. Resolving a loop is how GridMap differentiates between the teams involved. GridMap resolves each loop by using a set of principles and logical analysis to determine where to "cut" each loop. When the loop is cut, the loop can be strung out into a thread, with the team at the top of the thread having lost to the team at the bottom of the thread in an "upset". Unlike most other systems, GridMap identifies and displays every loop, and every upset (ranking violation) that results from the resolution of each loop. This assures that GridMap is not showing or hiding any bias in determining which games are upsets, and therefore, which teams are positioned at the top of any given loop. The pollsters would resolve the simple loop between A, B, and C subjectively, with their votes based on who knows what (point differential? who played at home? injured players? reputation?). Sagarin would resolve this loop with quantitative data, but would include data from previous season’s for this year’s team for some number of weeks into the season. GridMap puts up with no such nonsense. It resolves loops based only on this year’'s game results, and according to a set of logical rules. How would GridMap resolve the ABC loop? With no other game results, it WOULDN’T! All three teams would be positioned on the same tier. But as the season progresses, additional game results, in conjunction with GridMap'’s resolution rules, almost always resolve this and all other loops. After applying the resolution rules, say the loop is "cut" between teams A and C. The loop would now be strung out into a thread, with team A positioned at the top of the cut loop, or "thread", and B and C positioned on the thread on lower tiers, below team A. |____|