Discussion on different methods are ramping up – I’d like to make one suggestion on nomenclature.

**Graph Method:** Methods that have to do with determining what teams have beatpaths and beatwins to other teams. Examples are the current Standard graph method on this site, the Iterative graph method, and the Beatflukes graph method.

**Power Method:** Methods that take the Graph methods and then determine sequential rankings from them. Examples are the current strength-of-beatpower power method on this site, the Weighted power method, and MOOSE’s (what’s the name?) Total Paths power method.

I might have already misstated something, because I think I’m still unclear what power method the Iterative graph method uses.

works for me.

Have y’all ever graphed the teams late in the season without eliminating any beatloops? Moose was explaining that y’all get a ton of beatloops by the end of the season, which makes sense. Does this cause some teams to have everything beatlooped away? I would be interested in seeing of graph, of say the end of last season, without any beatloops removed.

I have a question about the iterative method. It’s idea is to find the teams that occur in the most beatloops, and break that beatwin first, at it will then break the most beatloops and thus keep more data to extrapolate from as one goes down the list.

So why does the iterative only look at the smallest beatloops first, get rid of those loops, and then moves to the larger beatloops? From what I gather, that reasoning just comes from trying to upgrade the standard method.

But what if we look at every sized beatloop at once to determine which team to eliminate. Instead of the dividing by how many loops and going to zero, and simple sum of every beatwin in the loops, and the team with the most often occuring beatwin gets eliminated. This would through one action eliminate the most possible beatloops. Recalculate and then eliminate the next team.

I believe this would retain even more data than the current implementation.

Under this terminology, the Weighted method is a type of graph method as it is just another way to break beatloops. Instead of breaking them all or breaking some based on flukes or duplicates, it breaks them by point spread. The weighted method does not affect the Power Method any differently than the other Graph Methods.

While I don’t suppose I’ve officially named my Power Method, I most often refer to the ratings as a team’s path score which seems like an appropriate name for now.

—-

Boga: I have personally viewed all of the final season graphs from 1970 forward (and will be posting them as time permits). I do not recall any team looping away the entire season’s worth of games on, or even near, the final week. There are usually a couple teams with no surviving BeatLosses, and a couple with no BeatWins, but never a team with neither. Personally, I am not interested in drawing an end-of-season graph with no loops broken as placement on the graph will be determined by the order the teams are listed in the input file, and there will be 13 arrows coming in and out of every team. The will also be pointing up, down, and sideways making for an unreadable graph.

The iterative method doesn’t look at smallest loops first simply because that’s how the standard method does it. Looking at smallest loops first is the proper way to go. Your argument is that looking at all loops will retain more data, however in some of the cases I have drawn out, it either makes no difference, or retains LESS data than our current methods. The reason for this is that while there are ambiguous segments of the graph, there are also solid segments. If you use all loops, the longest loops will include these solid segments in every slight modification of the path. Their appearance in all of these variations will make them get targeted for elimination first, when they wouldn’t even have been considered had the smaller ambiguous portions of the graph been resolved first.

Take this as a small example of what I’m talking about.

A->B

B->C

C->D

D->E

E->A

D->C

Everything is orderly, except C and D have a season split. Considering all loops, you get these:

C->D->C

A->B->C->E->A

A->B->D->E->A

A->B->C->D->E->A

A->B->D->C->E->A

Looking at the number of times each segment appears, you get:

A->B: 4

B->C: 2

C->D: 2

D->E: 2

E->A: 4

D->C: 2

So, E->A and A->B would be eliminated first leaving the rest. The season split would still be intact, but would then be resolved in the next step, leaving only B->C and D->E. 2 out of the original 6 links survived. Using our current methods, the season split is always resolved first and this would leave 4 links in each case if the C->D->C split games had balancing point spreads. The weighted method would leave 5 links if the point spreads were different, preferring either C->D or D->C.

One of the ambitious thoughts I’ve had for this is an interactive graph, perhaps done in something like Shockwave, where someone could select different views. I could see it displaying the graph with various options:

1. Displaying or not displaying all pre-loop resolution paths

2. Displaying or not displaying “hidden paths”. IE, Team A beats Team B and C, Team B beats Team C. In the current graphs you’d see A->B->C but the A->C path is implied.

3. The ability to display beatloop graphs.

4. The ability to display different hierarchy rules (MOOSE’s tiers, for example)

5. The ability to highlight Divisions or Conferences.

6. The ability to display links for upcoming games to make it easier to determine how they might affect the graph.

This is likely overly ambitious, but it should be do-able if someone had the time.

I think you could actually look at it as a three step process:

1: link measure

2: graph method

3: power method

2 and 3 are already defined. 1 is the data you use to weight a link. In the case of what we’ve typically been calling “standard” and “iterative”, it’s a weight of 1 for each win. In “weighted”, the weight of a link is equal to the point differential.

As I’ve said before, I think single-game VOAs from footballoutsiders would be a really cool link measure.

If you think about it that way Doktarr, then standard and weighted are the same graph method because they both subtract the lowest link from all links until the loop is broken.

Moose,

I believe you are missing a C -> E and a B- > D in your list above. Also, I’m not quite following you. Using my method, I see the graphs having a B>C>E and B>D>E loops left. Which would leave 4 of the original 8.

And when doing your iterative method, the first step would be to eliminate the C>D and D>C loops. That would leave

A>B>C>E>A

A>B>D>E>A

(The bottom two loops would be A>B>C, D>E>A and A>B>D and C>E>A, both those are wholly contained in the loops above, so are extraneous)

Now you are left with two beatloops, and A>B and E>A would be eliminated, leaving the same answer as my proposed method.

I’ll try to sit down and work out a robust example to see if I can find any differences.

Oh, and Moose, I completely miswrote what I wanted to see.

I wanted to see a graph that every single beatloop which occurs is broken. I’m curious, cause that could be considered the baseline for all the other methods to compare to, since the others retain some of the beatloop data in them.

In response to MOOSE #5

I would be interested in a system that removes all beatloops simultaneously. the way to do this would be to identify games that are part of multiple loops, and remove an equal fraction of them with each loop.

In this case, there are 2 loops (the double > is used for convenience as you will see later)

A>>B>>C>>D>>E>>A

and

C>>D>>C

the game C>>D is part of two loops, so reduce each loop by half.

First

A>>B>>C>>D>>E>>A

becomes

A>B>C>D>E>A

then

C>D>>C (remember C>>D was already reduced by half)

becomes D>C (as half of each game is removed)

for a total of

D>E>A>B>C

The good thing about this method is that it doesn’t matter in which order you consider the loops. The alternative way is

C>>D>>C

becomes

C>D>C

then

A>>B>>C>D>>E>>A

becomes

A>B>C D>E>A which is D>E>A>B>C

which is the same solution as before. I have a gut feeling that this would be a goo way to resolve beatloops.

Sorry if this is an incoherent post

Moose,

Yes, I agree. By that logic they are the same graph method, which makes sense to me because it’s the same core algorithm. For that matter, all three of the rankings on your site use the same “power” method – a path score algorithm.

Boga: Ah, you’re right, I did miss listing B->D and C->E.

Justin: I believe that what you’re suggesting is exactly what Boga is suggesting.

Justin’s example actually also leaves D->C which is redundant in the larger path but is eliminated by the iterative method. I have found some examples where this does leave more information behind. I’m going to take some time to decide if it’s worth finding all loops, because as I’ve stated before it increases the amount of work from about 20 loops, to into the thousands, maybe tens of thousands or more.