As I focus more attention to the Vertical Sums, there is a specific work flow that comes to mind... using a spreadsheet to design and experiment with the parameters on one page, and designing the output on another. This was the same process used early on to create both the follower and classifier scripts.

The plan for the vertical sum sheet will be to experiment with the sample size N and the number of rows to sum k.

Since we are working without guidelines, we will have to find them.

The concept would be to pick a sample size that is not data starved, but not so big that it loses volatility. Here solving for k first, and then making the sample size N a multiple of k makes the most sense.

Here we will be applying an interpretation of the "rule of 30". Since we know the distribution to be both discrete AND uniform, a value of k set to 10 seems a logical starting point since the pick N games have 10 digits each. And for N, we apply k x 30 for an N (sample size) of 300.

This would scale with games like Match 6 where k would be 49 and the sample size would be k x 30 = 1,470.

That is not a magic formula, but you have to start somewhere.

The basic idea is to roll the sums forward one draw at a time and record that sum. When you have enough sums, take the average of the sums (or alternatively, record the most frequent recurring sum) and then sum the last k-1 (9) draws and compare it to the average (or mode) and simply subtract the last 9 from the average (or mode) to get a guess. At the spreadsheet lab level, it is possible to record both the average sum and determine the most frequent sum and compare the accuracy.

While not as robust or complex as an AutoRegressive Integrated Moving Average (ARIMA), it still functions to analyze the time series lottery data from it's own past values.

This first sheet is where the design decisions can be made.

The second sheet will be used to experiment with what data should be output. This is where we would record the average and mode result of all of the k sums in the N sample size. Any other relevant data can be placed here.

When done, sheet 1 will help describe the per column script in Python, while sheet 2 will be a model of the output.

In order to fit a Vsum function into my app, I need to determine the output based on the framework... the table view would contain the 30 sums in the 300 sample size, and the stats card view would contain the average and mode of those sums and also calculate the last k-1 leaving you with a pick for each column.

When I designed the app, it was with pre existing csv files that can be updated. I also included a cache folder with the idea that maybe in the future I would need to generate a temporary file. This might be a use for one! A csv file that could be generated for display, then deleted when exiting the app... this way switching between functions for analysis could be done to compare data with the followers or classifiers and not need to be completely recreated.

Here is the best part... developing first as a universal stand alone script means I never have to touch the stable code base of the app unless it proves to add value. If the spreadsheet stage fails, Then a script never even gets written.

The hard part is done. I have created a portable framework. I can get back to exploring ideas again, only now with a proven work flow and targeted outputs. And if something does not fit the table/stats output, it can stay a single script. I cannot even describe the joy found in this hobby by automating updates. The whole GUI learning experience was worth the effort... even if that win is still elusive.