hypersoniq's Blog

So, going to try and play for the whole year. $14/wk budget. Cycle is 10 weeks (4 weeks of PA Match 6, 3 of pick 3 and 3 of pick 5), so that will be 5.2 complete cycles.

52 weeks @ $14 per is $728, so the expense is known. First week is the match 6, so the running tab is so far -$14

On the coding front, I made some big strides last year on creating my first GUI program for windows, so the 2026 goal is to finish the windows app, then recreate it for android. Time spent making sure the scripts were tested and flawless paid off so far in the app development, I do not see 100% functionality taking too much longer, it will probably take longer to make it look nicer. Taking time planning at early stages is making this a true framework, where any system I can imagine can be added in... only possible because I automated draw updates!

On the back burner...

1. Exploring vertical sums in the pick N games

2. Further development on the Markov Chain of followers, that will include planning a massive back test to check how many times each level of numbers matched per column... I am still uncertain how to even structure it.

3. Learning how to interpret all of this data I am generating, particularly in the area of using classification data and follower data together.

2025 ended up as a net loss of $185 and now that chapter is closed. Looking forward to the year and what all of the coding work might bring, there is huge learning potential, but a decent win would be a nice additional result.

Best of luck in all of your plans for this new year!

I will be creating view screens for data, one for each type of game...

1. two_column_screen - pick 2 mid and eve

2. three_column_screen - pick 3 mid and eve

3. four_column_screen - pick 4 mid and eve

4. five_column_screen - quinto mid and eve. Cash 5. Treasure hunt

5. six_column_screen - Match 6, MM, PB and Cash 4 Life

14 games, 5 layouts that can be used for either classification or follower data. Each has a python file in the ui/screens folder and a corresponding .kv file in the kv folder.

I will also need 5 more for the column statistics for each classifier game.

20 files... grunt work.

The nice thing about having the development environment set up from school is having the tools needed installed already. Notepad++ works for editing .kv files!

I may also put a launch icon together on the desktop to do test runs without always having to launch main.py from the command line. This will most likely span the coding time or the next 2 to 3 days.

Every step gets closer to a viable app!

That means with the click of a button, the app updates all 14 games of the PA lottery to the most recent draw, fills a progress meter along the way, and gives a message when done! Being me, I looked at the tails of all 17 csv files to make sure everything wrote correctly... and it did!

All of the progress is also being aware that this is eventually headed to android, but also runs on windows.

Callbacks instead of print statements, proper project directory layout, even using a background thread to keep the android system from falsely detecting a program freeze...

This is why it is taking so long, also it is my first gui app.

Taking the time to be detail oriented at the beginning is sure paying off now. Kivy even has a downloadable docker image so I do not have to start from ground zero with the android build when it is time. Already have WSL 2 (Windows system for Linux) installed on windows, so there should be no technical oversights when it is time to reach that milestone.

Update and exit buttons are wired and functional. Time to step away from it for the rest of the day and let the smoke stop pouring from my ears... it was a good day!

The buttons on the main screen don't do anything yet, but the splash screen then the main screen... complete with buttons and a bottom nav bar... launched with no errors!

This is all new ground for me.

Now I can start hooking the scripts up and making it all work... I will worry about making it look good later.

I really love coding!

So, the project is underway, and so much had to be altered! It is a completely different world when developing a windows app while keeping in mind it will also become an android app!

The main program could be named anything in windows, but it absolutely MUST be named main.py on android.

The data files could sit in any location in the windows project folder, but they need to be in the application space to not trigger read/write permission requests in the app.

So I am building along the windows project, but keeping in mind the android parts as I go. So much documentation to read!

I have managed to create the scripts as modules, and ran successful tests of all scripts. Created a config.py file that exposes the csv files and modified the scripts to find them. Right now I need to check the tail of all 17 csv files to ensure that the data was written properly, which is pretty much guaranteed by the update script logic, but verification at every step is important.

The next phase is removing the print statements and instead packaging the output to populate Kivy widgets. After verifying the csv's the actual GUI part starts!

The initial goal is to include the classifier AND follower scripts. Verified through some coding samples that what my follower script does is quite literally a first order Markov chain. I have included output of the most recent 10 followers to put some temporal context into the distribution.

This is not going to be easy, but the learning is off the charts right now! Stack Overflow is open in a window at all times, as is the Kivy documentation site and various Python docs. Feels like a real project!

Solving problems is what makes coding interesting, moving to the next level is reward in itself, even if the systems never produce a win!

I wrote 2 small "hello world" scripts. One was to test the base Kivy install, the other was to test the KivyMD install. KivyMD is a Kivy extension that allows you to use assets from Google's material design project. Cleaner, more professional looking tools and widgets, fonts, transitions, etc. Meant originally to replace the "Kivy look" with more pleasing GUI elements that would be found developing native android or iOS applications.

Both ran and produced the expected output.

When creating the project folder, after moving in the files that I would be starting with (.py and .csv files), I used the following git commands to set up proper version control...

1. git init

This initializes the folder to be a git repository

2. git add .

This adds all of the files to the repository

3. git commit -m "Initial commit of project CHANCE"

When looking at the commit history with the "git log" command, that will be the starting point.

Now I can work on scripts safely, able to roll back to known working points if needed, and develop sections in branches... only committing changes to the master branch when they are ready.

I did manage to get this started before the new year!

And coders don't really like surprises! (Unless a pick you generate happens to match the draw results...)

Tested all 14 games against the universal classifier script in 3 modes

1. With offset and window set to 0

2. With offset of 0 and window of 21

3. With offset of 10 and window of 21

This was to ensure that all games work, AND that the data slicing was correct when introducing non zero values for the offset and the classification window.

This allows the GUI development to finally begin!

Copies of all files, including the csv history files, have been placed in a project folder, git enabled (real version control, not just my ad hock file naming convention!) And basic documentation started.

Next up is to build the "hello world" in Kivy to ensure the libraries are properly installed... then it is off to the races!

Will start with the classifier and updater scripts... adding followers when ready. Still trying to add a temporal component to that, idea well is running a little dry... not exactly the same as "most recent appearance" in the classifier, but similar in nature.

The placeholder splash screen will just have text to start, followed by the main screen. Sub screens will have dynamically generated grid layouts based on each game.

Once the windows app is perfected, then it is on to a Docker container and Linux to package the app as an APK for Android. Because of the myriad of problems that can arise in a mobile app, it is imperative that the windows version operates flawlessly, including sanitizing input values on the settings page to avoid "index out of range" errors... I am gonna try my best to break it!

This will be the project until done, no specific time line... it is more important that it works! Then the goal will be met, a way to get picks without needing to ever touch the laptop... though there are still a whole host of projects waiting there, from moving from follower output to a first order Markov Chain to studying vertical sums with both code AND Excel powerPivot in the pick 3 to putting data into a real database where SQL commands can be used to find patterns and trends that I can't seem to spot... that WILL require the laptop...

2026 is looking pretty well organized as far as hobby coding goes, much to learn, much to do.

The output is similar. The pick is the same. The data collection is different, but the end result is the same, so why bother with a different script to do the same thing?

The change is how data is collected (list vs. Dictionary), processed (raw frequency count vs. Normalized Percentage) and output (distribution list for only the case of the followers of the last draw vs. Agentic extraction of that data by parsing the dictionary.)

So, actually, one will eventually replace the other, so the plan is to make that update to the windows version of the GUI and have everything finalized by the time everything goes to Android.

To be fair, the majority of systems I have dabbled in all have the same root, analysis of frequency in identifying patterns and trends. The classification is the only real departure from the trend. How might the info from each be used together? An interesting point to ponder...

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.