As was expected, the pick 3 observation of the frequency of draws from the neutral set of numbers was present, but less pronounced when moving to the pick 5... as would be expected when moving from 1:1,000 to 1:100,000. I expect the to see the same reduction when moving to jackpot games.

When dealing with the history as sorted order columns, there can be a reduction in the set because they are non replacement. Meaning that the expectancy of possible numbers per position can be altered by the limitations imposed by sorted order. For example, in a 6/49 like the PA match 6, the expectancy for the appearance of each ball is 1/49 *100 = 2.04 %.

However, in sorted order, each column is restricted to 44 numbers... the first column will not contain 45, 46, 47, 48 or 49... the last column will not contain 1,2,3,4,5. 1/44 * 100 = 2.27%.

The range for each column will be different, so that will have to be accounted for in the code.

In this jackpot scenario, it will be expected that a good portion of the numbers will be cold because they were not drawn in their positions. This will also need to be addressed. I am thinking that the distribution frequency should be coded in such a way that numbers in range with 0 frequency will be eliminated from the classification phase. I feel this will be some tricky coding. In a pick 3, all possibilities are covered in 10 digits... not so with a jackpot game.

With a lower expectancy, more data will be needed for training. The math was easier with just 0-9 in each column. To get the pick 3 numbers a chance to be drawn 15 times, the number of draws was 150. To do the same with an expectancy of 2.27%, the required training draws would be 681. Also the window of 7 draws may need to be expanded.

Since the initial window was determined by the max number of advanced plays, the same would probably suffice here... jackpot games can be played for 26 draws.

Obviously the requirement then becomes at least 707 draws need to be available in the history file. No problem with the PA match 6 having thousands... but it may become data starved with any matrix changes.

For each type of jackpot game, a new script will need to be created, it will not be as flexible as the pick N script.

And again it may not be the magic bullet, but it might be a decent tool for loading an abbreviated wheel. It would be very interesting to see how this all holds under the non replacement structure of the jackpot games. Would be cool to see a decent amount of NNNNNN draws in the Match 6 back test run!