My followers script itself is well over a year old. When I originally ran the first back test, it was 100% within Excel.

The idea was simple, loop the script with each digit as the last draw so I would know the top follower of each digit in each position, put these into a lookup table, and count the number of straight hits.

Of all possible "replacement" strategies, this one performed best, meaning at the time, it almost returned enough straight hits to make the imaginary $1 straight per day over the entire history come close to breaking even.

Here is the fatal flaw... you would NOT have known the most frequent followers of 16,000 draws (at the time) in the past! I look at all of the work I put into both the script AND the spreadsheet and then realize I broke the time line by using data from the future to test old draws.

What should I have done? The correct way to test the hypothesis should have been to create a rolling back test... one where older draws are calculated only using data that was available BEFORE that draw... one that indexes and recalculates one draw at a time for every row of history.

It's not like I don't know I make a ton of miscalculations at this stuff, what is important now is to realize when a mistake was made and take corrective action. Excel was the wrong tool, it is better for static analysis.

So with this understanding of why the data I had was incorrect, I can plan a proper back test using the current follower script.

I know that followers need data to start, so I cannot go back to draw #2 like I did in the excel sheet. If I use the first 1,000 draws to prime the data pump, that gives each number a fair chance of appearing 10 times as a follower for each possible digit. That is number of balls * 100 as a generic formula.

I know that the follower distribution returns a list sorted descending by frequency, so the highest follower per column would be something like distA[0].

I know the calculation would be if nextDigitA == distA[0] && nextDigitB == distB[0] && nextDigitC == [0] (for the pick 3) that a correct hit would be identified.

So, if the comparison is held in it's own function, it can be altered to check for other scenarios as well.

I also know that the data inside of the distribution does indeed represent a true first order Markov chain, as the higher the frequency, the higher the probability of that transition. Not perfect, not a guaranteed winner, BUT, the "memoryless" property holds... only the current state (most recent draw) is used to generate the transition probabilities to the next state.

So this now has to be wrapped into a universal script that can be used on a per column basis for any game. Now that I got some practice with structured data return, I can write everything to a dictionary structure and get the output more readable than the old version of the script.

Other metrics could include that when the next draw does NOT equal the current top transition option, how far off was it? Is there anything consistent about those errors? Writing those to a csv file for import into Excel would be the right time to use Excel in the process. If an error matrix is produced, maybe it could yield a "correction factor"?

This is one of those things that will take some time to think about before ever writing a single line of code, but the follower function is already written, just have to build the back test around it.

This is one of those posts where the idea starts to come together for a coding project. The broad idea is a proper back test of the follower script, mixed in with a few off the cuff ideas on what a solution might look like. The back test for classifiers was written once I had gained enough skill and insight to create a sliding test. After working on this idea, I will revisit that one and see if improvements can be made.

I will also print out which numbers hit when a straight match comes up. Curious...