hypersoniq's Blog

While the Markov Chain approach seems much like follower data, the approach is different because it is capturing the observed frequencies and normalizing the distribution percentages.

This allows capturing a single pick, which can be done in a moving window, allowing for back testing the entire history of each column of each game. From this concept, pick data can be collected and compared to actual results, and an error function can be developed by comparing the pick to the next draw.

It is on this level that the agent which will initially parse the dictionary and generate a simple pick can be transformed into a more robust construct that can pick not only on the Markov Chain observed transition data, but to also "learn" by reinforcement (reward/penalty) how to adjust that pick to take into account the observed errors along the way.

The output will still be the same, one pick.

Over the years I have tried many things without fully understanding what I was looking for. I think the firm idea is not just static analysis, but also adding temporal context. I have hope that this type of analysis can help understand the "churn" better, or how patterns can repeat, just with different numbers in a given time frame.

I think my problem may have been trying to black box the parts of the problem I did not fully understand.

Version 1 will be with the simple dictionary parsing "agent", but that allows development of the smarter agent and the back test data for later refinement. It changes the process by only coding what I know until I understand the rest.

Pretty sure I can crank out an operating script for a basic Markov Chain pick in time to add it to the GUI app... now there will be three choices per game...

1. Classification

2. Followers

3. Markov Chain Pick

Both 2 and 3 will use the full history, classification will still be based on a sample.

That should provide plenty of coding work for the hobby in 2026.

The first order dictionary would be a collection of the digits in the game followed by their observed transition percentages, such that 

0 ("to 0"= 0.1, ... "to 9" = 0.1)

...

9 ("to 0" = 0.1, ... "to 9" = 0.1)

The percentage is calculated by the number of times a digit transitioned to each possible next digit. There are ten entries for 0 through 9. The expected value is ten percent per transition.

The second order dictionary will be similar...

00 ("to 0"= 0.01, ... "to 9" = 0.01)

...

99 ("to 0" = 0.01, ... "to 9" = 0.01)

This represents the transition for each combination of the previous 2 draws, such that on Thursday, column 1 was an 8 and on Friday, column one was a 6. There are 100 entries and the expected value is one percent per transition.

So this generates 10 entries for first order followed by 100 entries for second order. In the pick 3, that is 330.

So the key is to watch where the observed transition percentages deviate from the expected transition percentages.

This will require larger past draw collections for a second order study, thus this part will be strictly for the pick N games.

The next step will be to read the most recent draw, and only display the relevant entries...

If they picked 9 0 4, the column 1 output would be the 9 entry, the 0 entry and the 4 entry from each respective column... then, say the previous draw was 7 7 7, the second order entries for 79, 70 and 74 would be displayed.

I could go further and reduce the output to the highest percentage transition and just generate a pick based on all of that data without having to sift through all of it. In this way, running the script does all of the work in the background and then just presents a pick with the highest transition percentages.

There will be details to consider and edge cases to test for, such as percentage ties, but this is the basic plan to start with. This could then easily be added into the GUI framework.

So, the vertical sums still need a way to be looked at. I have an idea that will use a rudimentary first order Markov chain... but first I need to apply it to the actual draw numbers.

The basic idea is to create a first order Markov model of transition states (such as the observed transition properties of 0 to 9 for each digit in the pick 3 history, accumulating the data to a python dictionary, which will then display the results. Because we know the expectancy, we can spot where it deviates for every digit. Pick N histories will also get a Second order Markov analysis based on vertical pairs.

Once the script is written universally, then collected sum data could be read in the exact same way.

Next, vertical sums would have a probability for each transition, as well as lead in vertical sums... the idea being finding ones that match! Subtract the lead in sum most likely from the vertical sum most likely and that is your pick. I will also have the regular horizontal sums profiled for reference.

The plan seems straight forward, code implementation will be the key. Count the historical transitions and compare them to the expectancy based on a discrete uniform distribution. Instead of sums becoming another layer of abstraction, they might just end up being a potential solution!

None of the lottery sites use ball images to display results, they use CSS. Kivy is not a web based framework, but the documentation indicates that there is an internal set of codes that can act like CSS.

Also, pre loading to a dictionary structure may help solve some issues along the way... 

1. No need to pre render views not used. I may not always want to view the column stats, so that data can be saved and rendered on demand. The same when using a value other than 0 in the window setting.

2. The column stats page can be generated on demand and be swiped away when done, preserving the original output!

3. The layout setup will have an easier time combining the output of bonus ball games, which are calculated separately.

I have also confirmed at the script level that the completion of updates will contribute a value of 1 to the progress meter, which is going to be scaled at 14... this way when the PA lottery drops cash 4 life, I only need to change the code in one place AND delete the button and associated csv files with an "update".

Also, each game will have 2 choices when selected... process classification or display followers. So now it will be a true framework as other systems can be added to this screen... all using the same history files! For initial simplicity, follower data will be measured using the entire history file, and the update of draw data is not automatic, in case you want to see the follower data compared to the next draw.

All of the other features will remain intact.

Two systems rolled into one app!

Windows development is right around the corner, pending results of the 14 game classification test...

Getting there, one step at a time...

Breaking up the side by side output from the universal classifier script into per column printouts.

Why?

Starting the Kivy app development can begin!

The basic process is to get the data to print out per column, as these prints will be redirected to a kivy widget.

The test is a giant launch where it will be called to process all 17 games in sequence. The only thing that changes is the low and high ball arguments and the name of the csv file to process. This is the chance to permanently suppress any possible errors. This has to be 100% universal and working before it starts populating a kivy grid layout.

The updater works as far as running and providing 100% correct data to all of the csv files. They just need the prints removed and the percentages entered for the progress meter.

This should make the process relatively quick to get some grid layouts together.

Some of the development will take longer, such as being able to produce graphs and getting the ball graphics sorted out, but there is a general idea of how it will look.

That "look" was done on a sheet of paper. No wireframe development needed.

My goal is to have the windows version done by the end of the year. 

First it must be functional, then I can tweak the look and feel of the app BEFORE even thinking about porting to Android.

Since it is not for sale or redistribution, I can borrow graphics straight off of the PA lottery site... that will be a huge time saver!

I do not think it would be too difficult to incorporate the follower scrips for any of the games, I already converted that script to a by-column output that will be easy to place the output into kivy widgets side by side. Adding this script makes it more of a framework than a single solution, and that was part of the overall vision for the project.

The core systems (followers and classification) have not yet proved effective in converting picks to winners on a regular basis, but each HAS picked at least 1 straight hit this year. Have to start somewhere, right?

Remember, the overall goal here is not picking winners, it is creating a multi platform (windows and android) application from a single code base AND learning graphical user interface coding. On that front, I predict the same path as learning to script... encounter problems, solve them, refactor... in a loop until it works as intended. THEN I can go back to trying to win something. Also a key to this process will be learning how to compose documentation.

On that front I created a project folder called "CHANCE" and enabled git version control on the folder. This way, new features can be added as branches and rolled into the master branch only when 100% functional. The next step will be to do the activities above and start populating the project folder with the finished scripts and clean copies of all 17 csv files. Then a graphics folder will be added with everything needed for button images for each game and the number images. Sticking to Android patterns, that will be the "img" folder.

Gonna be a busy few weeks!

While playing the pick 3 today, halfway between printing out the tickets the machine spit out a free cash pop ticket for the $1 "Lunch Break" draw (1:35 pm, draw # 94) with 5 picks on it.

Did not pay for it, they did not charge for it, it was a give away promotion of some sort.

Numbers and amounts were as follows...

7  $7

8  $5

12  $15

13  $5

14  $15

So I spent $1 straight for the week on both mid and eve draws ($14 total) and when I checked the "gift" ticket, number 14 was drawn... $14 spent, $15 won... first profitable week on this system in a little while!

They used to give away Keno tickets before. Won $100 on that.

I now have to take each of the scripts and modify them to work with expected output, not just print statements.

For the updater script this is including the 7.14% completion addition at the end of each update rather than printing "2 rows were added to PAPickThreeEve.csv"

For the universal classification script this will be much more difficult... I have to rip down the logic used to buffer and display columns side by side in the output. I Must verify this at the script level first... by keeping the prints and getting them back to whole column printouts... this means moving the multi-level sort AND keeping the optional output if the window variable is set higher than zero. Also, the jackpot games will need to suppress zero information... if a number was not drawn in the sample, it will be hidden in the output. That should be simple as I give the MRA(most recent appearance, or draws since it last showed up) a value of 999 if absent.

Then I need to run the newer versions against the older versions to compare that the output is the same.

Then they will just need the data output redirected into the appropriate kivy widget instead of being printed to the console.

Then... the classifier must be run using each of the 14 games to ensure no surprises or errors... that does not take too long, but it is an exhaustive test of the suitability of one universal script for all games.

Only then can the process of designing an application loop take place... this will be for the windows desktop version. After that works, the entire environment and project folders/files need to be dropped into a Docker container as kivy for android needs a linux environment and that is just easier to do with docker than spinning up WSL or porting to the raspberry pi.

Getting the app running on windows is priority one, and the android version of the windows app for an android device... but none of this can begin until the scripts are production ready. Not even setting a time frame as GUI apps are brand new to me.

It will start with a splash screen, giving buttons to update or process a game.

The game selection screen will have a button for each of the 14 games.

When selected it will process the game chosen with the default settings of

Window = 0 (how many draws after a snapshot to classify)

Offset = 0 (how far back in history to start, in days)

Sample size = 15 (how many fair chances to give each ball to appear. Formula is high ball × Sample size)

The data view will be selected by default, with column data presented.

There will be a "settings" button which allows adjustment of the window, offset and sample size, this window will have buttons for recalculate and exit or cancel and return.

The ball view toggle switch is also on the main data screen. Also a button to show column statistics (more on that later) 

Also the generate all neutral QP button and the choose another game button.

I can almost see it!

It is time to get real about learning the Kivy framework for the app.

One behavior I had to test was launching each update script from within a new script, making sure there are no glitches in execution. This test went very well, it updated all 14 games with one single run command! I spot checked a few files and everything went as planned, even with the jackpot games that have a bonus ball!

One replacement I will need to make is to replace the console outputs that show which files are done with a number that breaks things down to 100% for all updates, this will be read by a Kivy progress meter! It will start at 0% and jump to 100% when done. When a csv file is updated, the output will be

progress = the percent of each game update success, roughly 7.14%

The classifier script is called with arguments specific to each game type, so a list of buttons representing all games will be presented. The call with arguments will be coded in the onButtonClick() function. I tested the powerball to execute the 5 white ball file file with a ball range of 1 to 69, and the power ball file to execute with a ball range of 0 to 26. The test had to run them sequentially and it did! Within this button click logic will also be the grid layout for the data, which will vary by game type as well.

In the final output will be the data I currently produce, which includes the number, the frequency, the classification (C, N or H), the percentage of the frequency to the sample size and the number of draws since it's last appearance.

Here is where it gets fun...

There will be 2 views set to a toggle switch. The data above will be in the "Data View", the other side of the switch will present the "Ball View", where the columns will contain graphics of the balls (just like on the PA website) with different color backgrounds representing Hot (Red), Neutral (Gray) and Cold (Blue). This ball view will be the quick visual summary, while the data view shows the breakdown of results.

At the bottom will be a button that lets me choose another game, and a button that will exit the program. The navigation buttons will change via screen context, but exit will be present on all screens.

So that is the basic vision for the app in this phase. If I can make all of that work, then it will be a success (even if it never produces a winning pick). I have a huge head start because all of the scripts that do the work are already written and tested.

The end user story for the Android implementation will be

- I have the ability to update draws for all games anywhere at any time, no laptop needed

- I have the ability to run the classification script from anywhere at any time for any game, no laptop required

- reasonable run times will allow going from app launch to data in minutes. <3 minutes is the current observation.

Obviously other ideas will pop up, and I will then be holding an entire framework on my phone! If I want to put in follower distributions, it will be a simple addition to the functionality, but the fully updated data will already be there... and unlike most other android apps... no ads!

Starting as always with the pick 3 evening data. Interpretation will take MUCH longer. Having the plan in the previous post was helpful.

The summation of the vertical sum when compared to the lead in sum is a simple subtraction of the horizontal sum from the vertical sums, but it was kept in to see where the numbers come from.

Ranges:

Hsum is 0 to 27

Vsum in each column is also 0 to 27

Sum of vsums is 0 to 81

Lead in vsums are 0 to 18

Sum of lead in vsums is 0 to 54

There is much more to do, such as distribution and figuring it all out... but the concept for the current data was mere minutes to put together.

I am going to try some software called LextEdit, which allows running straight up SQL queries on data sources such as excel sheets and csv files... that could prove interesting at creating good views of the data with the full power of SQL.

It is definitely more of a "back burner" project as I continue to navigate the Python GUI world. The basic start at seeing if it is useful will to grab random sets of 4 consecutive draws and see if the data exists in the first 3 to arrive at the fourth. It may or may not... the randomness is still there.

I do not have a day off until Wednesday, so that is when I hope to put a pick 3 sheet together for the PA mid and eve games.

So, from the updater csv files I will import PAPickThreeMid.csv and PAPick3Eve.csv into their own sheets. This will give the first 4 columns of Date, ball 1, ball 2 and ball 3.

Will have to skip the first 2 draws so the formulas will have a full vertical set to measure. But the plan is (starting from the E column...

Col E will be the standard horizontal sum.

Col F, G and H will be the vertical sums

Col I will be the sum of the vertical sums

And finally Col J, K and L will be the "lead in" vertical sums, such that if the last 3 draws were.

247

103

785

The lead in vertical sums are the sums of the oldest 2 draws, so from the above example 3, 4, 10.

This will hopefully make it easier to tell which sums might help with prediction, as the lead in v sum + your pick will give the 3 draws needed to have a v sum and an h sum.

While I will be just getting a feel for the data by looking at it, and profiling the bell curve for each, this may just be the perfect application of my old follower script, as it will display the distribution of sums that tend to follow each of the 28 possibilities (or the 19 possibilities in the lead in sums)

Because of the modular column by column approach of the follower script, it needs zero modifications to be applied to this new data. It will also scale from the pick 2 through the pick 5 and beyond. The time invested tweaking scripts for systems that did not directly work proves useful because the code is still reusable! Framework building blocks...

Also have a few days to think and imagine before writing a single formula. Like adding an L column to get a sum of the lead in sums... going all in on the sum theme!

The concept of sums is not new, but it is something I have not worked with. The idea comes from the world of machine learning, in particular feature detection and feature extraction.

The way sums seem to be done for lottery is across one row. Such that a pick 3 number of 1 3 9 has a sum of 13. This provides spatial context to the draw combo. Collecting this data and graphing it will show the distribution of draw sums, compacting the range of all 1,000 possibilities into 28 sums (0 through 27).

From time series analysis, I will be adding a vertical sum of the last 3 draws (for pick 3), this will have the exact same range and provide a temporal context for each column.

What I am looking for is some way to correlate the vertical sums and the horizontal sum to find patterns that emerge that are just not visible when looking at the raw history results.

If you look at the last 3 draws, the horizontal component is just as random as the numbers themselves, however, you already know 2 of the 3 components for the next vertical sum...

The spreadsheet should be super simple to create. Summary statistics on the distribution will take a bit longer. Nothing too difficult. Then the part where actionable intel can be gleaned from the data may take quite some time.

The vertical, or "rolling" sums seem to be more useful than the rolling averages also found in time series data analysis, particularly for the nature of lottery data.

Wouldn't it be interesting if getting a pick was essentially like solving the bottom row of a sudoku puzzle?

Outside of dividing the draw history into a division of sum ranges, what else can be done?

In a pick 3 it is easy, all sums fall between 0 and 27, pick 4 between 0 and 36, and pick 5 between 0 and 45.

Looking at a plot of the sum ranges should form a bell curve around the middle sums. Playing within some range of sums around the middle should present some percentage of all outcome possibilities.

What about adding another direction... previous draw sums? See where they might intersect.

The number of vertical sums would be the same as the number of balls in the combo... 3 for pick 3. 5 for pick 5.

So if there is a Gaussian curve created by the horizontal sums, there might be another one created by the vertical sums, in the same exact range, only in each position.

Only unlike horizontal sums, you already know 4 of the 5 digits for the next sum...

Got to fill the free time created with update automation somehow...

The passed variables work as expected. I even discovered an unused variable that remained from when I used expectancy +/- 1 standard deviation instead of the inter quartile range.

The universal version of the script had worked for the Match 6, Cash 5, and Treasure Hunt data sets, but it is throwing some strange errors when trying to run the pick N game data...

I have a feeling that tracking down these errors will take some stretch of time. Fix one, another, different one appears... good thing my version control has all of the previous working scripts intact!

So far...

Index Out Of Range... that was fixed by passing in the low and high balls for each game. Also by creating a new variable that adds one to the high range as python's range works as range(includes this number, excludes this number) such that for pick N, the range(0,9) only includes 0 to 8, the correct approach for 0 to 9 is range(0,10).

Error processing the frequency list... this worked for the jackpot games, because you ignore zero values to get the distribution of the present numbers... there are no zero values in the pick N games. That was fixed with a peek inside the frequency list with an if statement... if zeroes exist, it is a jackpot game, if not, it is a pick N game.

Had to rework the flowchart to make sure the execution was still following the original design. It is.

So this is another time killer. I have to print the contents of the frequency data ahead of the line that is crashing execution for the pick N games. I need to see that the passed variables are passing and that the frequencies appear as expected. The comment for sections like this is always "TEST PRINTS - REMOVE WHEN RESOLVED" so I do not forget to remove the troubleshooting code.

This is the type of project where resolving the operation to just one function is required because I want the app to run with as few functions as possible. I know it is possible to reduce it to 2 scripts, because that is how the updater works... 1 script for 11 games and 1 script for the 3 with bonus balls as they update an extra bonus ball csv.

I may end up having to do the same with this part as well, one script for the jackpots and one script for the pick N games.

That is the interesting part of kivy, a button click can set up and launch an entire script... so when a game is chosen from the menu, it will choose both the correct script AND the correct settings.

I could be overthinking this...

Never mind... figured it out!

So far tested with 2 distinct game types, pick 4 mid and Match 6... will test the others.

Summarizing the project so far...

Updater... 2 scripts, ALL games.

Classifier... 1 script, ANY game.

Crushed the goals remaining for this year. Onward to GUI development!

With the successful multi game updater and making measurable progress with the parameterization of the classification function, the development process for the GUI app which unifies these scripts will probably start in a week.

Seeing the demo app for Kivy shows many interesting options, such as a progress bar and being able to add a heat map display under the data, so cold, neutral and hot can have different attributes such as background color.

2026 is also the year to work on a formalized process for phase 2. There will be ongoing changes, such as consistent code commenting and generating documentation for the project.

This is more about the completion of a framework than a real effort to find a working system at this point... development and learning are my favorite parts of this hobby anyway, a hit is just icing... phase 2 development is where the next round of ideas will be created and explored.

I can always pull the plug on actually playing at any point, but I do want to have a go at playing a solid year, 2026 is that year. Whether I end up playing out of pocket with zero wins and end up losing $728 or I catch a win or 2 between now and 12/31 to have them fund the ride... it is ON !