OPR Breakdown Calculator
 

As per this post, I've created an app that calculates total and component OPRs for each team at an event. It requires an internet connection to get the data, but it will save the data as a CSV file for easy importing into Excel or a similar program, Tableau included.

Requirements:
Python 2.7, a Free and Open Source programming language.

On installation, make sure the Tk libraries are installed, which are required for the interface.

If there are any errors encountered, message me with the error log and how it occured on CD, and I will make sure it's fixed.

DOWNLOAD:
Git Repository Link
Direct Download Link

Future plans:

• Caching/Locally storing event data
• Minimization of bandwidth usage
• Event Listing Refreshment
• Abstraction to handle addition years' data

Re: OPR Breakdown Calculator
 

How are you handling surrogates and DQ ?

Re: OPR Breakdown Calculator
 

At the moment, I'm treating them as if they were not. Which means, that the component OPRs are non-representative of their representative values under the total OPR. However, I propose a solution:

Total OPR should be calculated via the match results, without modification, with Cholesky Decomposition.

The component OPRs, however, do not take surrogate/dqs into account. I propose that, for matches with surrogate/dq'd teams, those teams are not credited for that match: for their row in matrix A, none of the columns are incremented. However, for the non-surrogate/dq teams, the columns representing their alliance partners are incremented. So, matrix A will be asymmetric, which would require a different way to solve the system.

At the moment I'm occupied and cannot test this, but when I do I'll edit this post with my results.

Re: OPR Breakdown Calculator
 

There's a discussion going on over here as well:

http://www.chiefdelphi.com/forums/sh...73#post1455773

Re: OPR Breakdown Calculator
 

The only problem I see with that is DQs. If a team is DQ'd and doesn't play, does it make sense to include the 2-team alliance's score in the DQ'd team's OPR?

Doing what you suggested above does not cause the matrix for the normal equations to be asymmetric. It will still be square, symmetric, positive definite. It doesn't require a different way to solve the system.

I use the following nomenclature to avoid confusion: [A] is the alliances design matrix. It is a binary matrix (each element either 1 or 0). Its dimensions are 2MxT, where M is the number of matches (therefore 2M is the number of alliances) and T is the number of teams.

[b] is the column vector of alliance scores. Its dimensions are 2Mx1. Its elements come directly from the alliance scores in the MatchResults table.

[A][x]≈[b] is an overdetermined system of equations: there is no exact solution for [x].

To find the least squares solution for [A][x]≈[b] you can form and solve the normal equations.

Set [N]=[A']*[A] and [d]=[A']*[b]

Then [N][x]=[d] are the normal equations.

[N] will be square, symmetric, positive definite.

[N][x]=[d] has an exact solution, and that solution is the least-squares solution to [A][x]≈[b].

I took the MatchResults data from the ININD event, formed the design matrix [A], manually removed Red Team1 (5010) from the first match, used that modified [A] to compute N=[A']*[A], and tested [N] for symmetry. It was symmetric. I successfully used [N][x]=[d] to compute [x].

So bottom line, mathematically what you proposed creates no problem for the linear algebra.


[EDIT] BTW, nice work on that Python script. It worked for me straight out of the box :-)