Stochastic Programming in FPL - a Technical and Non-Technical Review

I'm ashamed to say that the application of stochastic programming to FPL might be the best idea I'll ever have. Like most good ideas, it came to me in the shower - I stepped out, dried myself off, cursed myself for not thinking of it about a year earlier, then discussed the idea with Sertalp Çay (who requires no introduction, since his online following is a superset of my own).

We traded diagrams mapping the idea, and inside 2 hours Sertalp had written a comprehensive implementation of the algorithm - it took me another 3 to catch up.

Stepping back from the particulars and running a few solves, it became evident to me that we'd taken the biggest step forward in our ability to model the FPL decision process in years. It felt like this was the "right" way to tackle the problems that we'd spent almost all of our effort in FPL optimisation struggling to solve (see: free transfer penalty, price point incentive, sensitivity analysis, etc).

Here we are, a year and a half later, and FPL stochastic programming has changed the world! Just kidding - it's not caught on in the analytics community in any capacity. As far as I know - and I'd be thrilled to be proven wrong - the number of people who have bothered to write an implementation of stochastic programming for FPL is stuck at 2.

I think one of the reasons for its relative non-adoption (compared to inferior methods of ensuring flexibility, like sensitivity analysis) is a communication problem. Sertalp has hours of Youtube content explaining other concepts and giving detailed implementation tutorials, which I think most FPL linear solvers enthusiasts have relied on, but I have done nothing in explaining the concept of stochastic programming in FPL beyond an initial Twitter thread.

This post is an attempt to put this right, and provide fragments of understanding which may previously have been inaccessible. This post assumes the reader has some understanding of FPL analytics, and especially EV in the context of FPL - if you haven't yet had the pleasure, I recommend this introduction.

#An explanation ...for anyone interested

#Some background

In this post, I am going to be talking about EV, and not FPL points. This is because I have lost touch with reality, and I spend my days in an ethereal, theoretical ocean realm from whence grass cannot be touched.

However, I will convince you that this manner of thinking makes sense in a "real world" too. Let's say, hypothetically, my goal in FPL was to have control over my distribution of points outcomes; I might, for example, try to maximise the mean average number of points I am expected to score.¹

If I wanted, I could cleanly split the task of maximising points into two distinct problems to be approached independently:

1. Accurately projecting the value of assets
2. Selecting assets to maximise their combined projected value

To make this division, rather than trying to frame the problem of controlling points outcomes some other way, is the essence of the philosophy of EV in FPL. It is not the only way to think about the game, but it is a pragmatic and internally consistent system.

Let's say we are more interested in step 2 than step 1, which means we are interested in fine-tuning our process conditional on existing projections. Then the nature of the projections themselves - and, as such, any connection to actual value as opposed to expected value - can be marginalised from the equation.

Before we go on, it's probably worth describing what an FPL solver actually does, and how it does it.

There is a common belief that the ultimate purpose of an FPL solver is to generate a plan, or even a set of plans; I think this should be considered a misconception, albeit a very easy one to slip into. I think that the purpose of an FPL solver is instead to generate a decision. The output we care about is the set of actions to be performed before the next deadline - this is a lineup order, a captain, a vice-captain, a set of moves, and a chip to be played (or no chip at all). This "decision" is more accurately a combination of many, many decisions, but since all these decisions are very deeply interdependent I will refer to the combination itself as "a decision". This decision will, in the case of most solvers, reveal itself as subset of a plan, but not necessarily.

(Diagram of a function with an input being a set of FPL decisions)

A solver is composed of a model, and some mechanism for finding an optimal solution for the model.

The model contains a set of constraints (e.g. a squad is limited to 15 players, the captain and vice-captain must be different players, etc) and an objective function - a function into which we can input decisions, and which will spit out some value describing the decisions' quality. The maximum output that the function can yield is called an "optimal solution", and the input (i.e. decision) associated with this output is an "optimal decision". For example, the most obvious objective function is an estimate of the EV we are likely to accumulate over some period if we follow through with the input decision.

In the context of FPL solvers, we are much more interested in the input corresponding to the optimal solution than the optimal solution itself; in the example just given, the objective value has some meaning; however, in practice, the objective is usually some heuristic with very little concrete meaning.

The mechanism for finding an optimal solution to the model could be one of many algorithms, depending on the nature of the model. The models discussed in this post (and likely almost every post on this site) are linear.

#The problem

Almost every alteration I make to my model has been motivated by my desire to balance grabbing EV with maintaining the ability to react to change.

There are many ways to frame "the ability to react to change", but I think some clarity can derived from splitting this the concept into two (potentially overlapping) components:

• Understanding and accounting for the value of information (short-term flexibility)
• Ensuring paths are robust to change (long-term flexibility)

FPL solvers are greedy by default. The objective in FPL is to score as many points as possible, and solvers pursue this objective with unrestrained optimism.

They are also deterministic; strategies are developed by solvers under an implicit assumption that EV in the future is set in stone - in fact, one of the very few things that we can be certain of is that the EV of every relevant fantasy asset will change. Without modification, there exists no mechanism to ensure future plans are robust to new information or unexpected events, nor does there exist any way to make different plans for different future scenarios in a consistent way.

(Visualisation of uncertain DGW dist'n of outcomes and mean EV)

To make solvers practical, we have to try to reign in this optimism and account for the non-deterministic nature of the game.

#Past solutions (and their problems)

• A Free Transfer Penalty is a bone-headed but pragmatic way to make the solver less greedy. Effectively it says "If you hold off on making a move when there is one available, I'll give you $p$ extra points".

  👍

  👎

  The penalty provides an incentive to roll a single transfer in the current gameweek (for short-term flexibility), but the concept comes into its own when applied indiscriminately to future GWs - even when 2 transfers are available. Using the penalty in this way leads to plans which don't use all available transfers, i.e. which plan to burn transfers. These "skeleton plans" have only the essence of a plan booked in, and gaps elsewhere. Plans generated with this penalty are more robust to new information in the long-term than plans without, as associated plans are simpler and more pragmatic.

  The penalty is a simple solution to an over-simplified version of the flexibility problem. It isn't enough to have gaps to fill in; often change will be so extreme that whole plans get thrown out the window. The free transfer penalty alone is unable to provide robustness for situations where extreme flexibility is required, except in suggesting not to plan ahead at all. "What is the value of $p$", you might ask? "About 1.5" I might answer, before refusing to elaborate. The truth is that a well-tuned penalty is dynamic, and there is no scientific way to calculate it at any given time.

  All in all, the free transfer penalty is a handy trick for quick-and-dirty solves, but it does not provide a comprehensive solution.
  
  

• Sensitivity analysis is a slightly more sophisticated attempt. Assets' EV can be liable to change in unexpected ways over time, due to increasing/decreasing minutes expectations for example, or perhaps changes to our estimates of players' underlying production rates. All these changes are realisations of an accumulation of information.³ In sensitivity analysis, we model this change and simulate many instances of information realisations. A solve is performed on each realisation, and the more common solutions are considered the more robust (Find out more here).

  👍

  👎

  By simulating scenarios, we can exploit any understanding we have of the distribution of unknown information. For example, suppose we know of a 50% likely double gameweek in 2 GWs time. We can run half of our information simulations with the double realised, and half without.

  The nature of sensitivity analysis is more deterministic than it ought to be. Each generated scenario corresponds to a single realisation of information, and, from the perspective of a given point in time in a scenario, the future of the information realisation is known - this is to say each scenario is deterministic, and therefore an imperfect model of the FPL decision process. The aggregate of these imperfect models is another, more balanced, imperfect model. The nature of the aggregation itself is also problematic: the best insight we can extract from sensitivity analysis is "Asset $A$ seems to appear in optimal plans ~$Y\%$ of the time". Is $A$ really an essential component of these plans? How much worse are optimal plans which exclude $A$? What if, when $A$ appears in optimal plans, it makes it barely, but when they exclude $A$ they do so comfortably? WHAT THEN? Sensitivity analysis has no answer for such questions, because it describes modal outcomes rather than the expected outcome. Insights like "Asset $A$ works especially well with asset $B$" are possible to extract, but very tedious to do so.

  As the loser who built the first model for sensitivity analysis in FPL, I feel qualified to say that it should have been the last.

#The new solution

#...for practitioners

(Scenarios modelled vs. solve time graph)

(Typical primal/dual graph)

(Simplified python implementation)

(Link to github repo with full demo)

#...for losers

(Mathematical analysis of stochastic programming)