hypersoniq's Blog

By looking at how I sorted things when printing to the console, I can see I have a disconnect because the data is not just printing out, but being packaged as a return value per column. I should just need to sort the return data structure. Also, zero frequency numbers in jackpot games have returned... I had those ignored in the old code, as well as the multi level lambda sort. Have to rewire those lines in the current context of the return values.

Not done yet, but at least I have an idea of what changed, so the solution can be targeted to specific lines of code.

Also, I thought I had a novel way of handling bonus games where it runs the scripts twice, as I have the white balls and bonus balls in separate csv files... but the second run does not allocate an extra column and therefore does not appear. Not sure of the exact problem yet, but it sounds like a simple adjustment in the meta data for those bonus games.

So, problems, but not major problems.

While not setting hard deadlines as this is the goal for all of 2026, I hope to be able to craft a pick from the windows app by the time the pick 5 cycle comes around. (A little more than 5 weeks). Looking forward to when this is on Android! The discipline part is making sure the windows version is 100%, as this greatly increases the odds of a smooth android port.

Onward!

 

Update: almost there with the follower script output... it is back to being sorted by, and including the frequency. Column stats for the follower still need a bit of tweaking, mostly just layout/UI stuff. Brain cooked for today, back to it on the next coding opportunity.

A s a bonus, the data matched exactly the output of the original script, so the back end remains solid!

The GUI app is running! All functions are operational without crashing, and the data displays cleanly!

Somehow I lost my sorting, and have to fix followers to show counts, but it ran on multiple games with a clean exit!

I am way ahead of where I thought I would be at this point... but not at the finish line just yet.

Serious progress has been made! The updater works flawlessly, and each of the 2 main scripts executes without syntax errors... now the tweaking of output is the next level... have to get the output to match that of the original scripts.

So the road map is as follows...

1. Fix the data output to restore sorting and putting the data where it belongs on the output screens

2. Make it look pretty. This includes making images and icons for "branding".

3. Write the technical documentation for the windows version.

4. Get it 100% polished

5. Start the android implementation.

I know it sounds ultra simplistic, but this is a huge step for my coding journey... I am starting to truly understand how separating layers into a framework is done, and why. Writing the game meta data file that connects the user interface to the back end scripts was an involved process... that it mostly works is crazy!

End to end run with a clean shutdown! The data output should not be too hard to fix... i hope. 

One immediate benefit is that I am getting much better at interpreting python trace errors back to their source AND figure out what went wrong... so much easier when you try things that are being processed and catch errors with descriptive messages.

This is so much more satisfying than following a tutorial, feels like real learning!

What a coding day!

But thanks to some research and documentation browsing, I will only need to make 4... dynamic column allocation! Part of a Kivy screen is python code, and part is a language for screen layout in a language specific to kivy... an exact analog for the java/kotlin android files with their xml layout files, which means I can read the header row for each csv file and dynamically allocate columns on the screen!

The difficult part to figure out was the need for a "logic layer" that glues everything together... what Python was made for! Here I have meta data that includes arguments for function calls based on each game's configuration. In this way pick 2 knows it needs 2 columns, while bonus ball games and the match 6 know they need 6 columns. This takes the place of when I run the scripts having to enter the specific configuration of each game in the function call. This output configuration can be used for both the classification and the follower scripts. The second set of files will be needed to display the column statistics for the classifiers.

4 files instead of 20! The added benefit is the ability to add any game configuration in the future... such as if they bring back a variant of the Super 7... with only the need to add a csv file and it's associated meta data profile.

Got the idea while searching stack overflow and found guidelines in the kivy docs on implementation.

Did a test render for the pick 2, and the screen was clean with perfectly aligned sample data, so the next step is to fully wire in the follower script and compare output to the original follower script to ensure it matches. 

Getting there!

This time the 3/6 was on a QP line, and the other 2 from the 5/18 were on the other QP line, but back at net $0!

So last year, the process was entirely limited to the classifier output. Pick a line that had all neutral values, the highest when sorted.

This first pick (the match 6 line) was stitched together using the classification AND the follower output.

1. Run both scripts and split screen the output for each.

2. Instead of just picking the highest neutral line or the most frequent follower, find the number in each column that sits highest on BOTH lists.

3. Record result and play for the cycle.

Sometimes that number was not the highest neutral, nor was it the most frequent follower. In fact, 2 of the 6 numbers selected were classified as HOT. This part of the selection process will be refined throughout the year.

I may not even hold the same combo for the full cycle, but this start with the Match 6 gives me 4 weeks of GUI development time.

That is where the true purpose of the GUI project sits... it does not generate a pick, it gathers, processes and presents data. It is still on me to figure out how to interpret the output.

At the onset of the idea was to be able to generate this data quicker and easier than the process I had in place. This gave me the idea of making an automated draw history updater, which works! I go from the manual process of copy/paste updates on the games I play (at the time) to updating the histories of 14 different games in seconds with a button click. This part of the GUI is already wired and working! The next part was wanting to be able to view the output of either script, that is where I am working now... the screens are getting there with each coding session. But now it still requires the laptop.

With the android part of the puzzle, I will be able to generate and look at the data from anywhere, anytime with no laptop needed!

The end goal is also to keep the framework flexible, so that any new script that can generate a different data view can be added without difficulty, to both the windows app AND the android app. This is where time taken now will yield benefits in the future.

I have a true MVC (Model, View, Controller) framework, where the data and the back end scripts are separated from the UI layer, and intersect at the logic layer. When the app is fully functional, I can go back and tweak the UI components to make it look good without affecting the functionality. The difference between the chaos of scripts and the elegance of a well defined framework. Thanks to Kivy, I can leverage my skill with Python for all of it, no dabbling with other languages or some other framework with it's own learning curve and particular quirks... it is a clean sheet build that is being engineered, not just slapped together.

The process is surprisingly similar to android native development, where a screen is registered and enabled in Java (or Kotlin), but has a separate file to control the layout (kivy's own .kv files, similar to android XML layout files).

Because I chose the KivyMD path, this allows incorporating Google's Material Design UI elements, so I can go for more of a native android look and feel vs the more utility based standard Kivy elements. I have not even made images yet, that will be a mini project unto itself one day... a logo, an icon, button images... all things to learn and experience.

With how challenging this small project is, makes one really appreciate Todd's wizardry with creating, updating and managing the LP!

So, there were 3 numbers on one of the 3 lines, and one each on the other 2. 3/6 pays $2 and 5/18 pays $5, so a $7 win! This puts the year's net loss from -$14 to -$7. The 3 on one line were on my picked line!

I started exactly on the 1st, but you can pick a different start day of the week, so playing Monday at the end of December let me pick 7 draws, starting on Thursday (Jan. 1st). Ticket is good through Wednesday, then I will pick up another, but before Thursday since I can pick the day to start. This "day of the week" feature allows not missing a day due to the kiosk being out of paper or the kiosk being offline (things that happen enough to warrant concern!)

The Millionaire Raffle ticket was a big nothing burger, but that was on last year's budget.

Even though it will be quite some time before the GUI app is ready to roll, I kept the old scripts, so numbers can still be crunched and I do not have any stress taking the needed time to ensure a 100% functional windows app, because that will ensure a 100% functional Android app on the first try!

Sticking with both goals, playing and developing.

This might be the only time I am able to cut the play expense in half with a single draw... with the Match 6, anyway.

So the premise is simple... we will stick with the pick 3 to keep it simplified.

A follower distribution is simply counting how many times each possible number has followed the last number drawn in each position. In a discrete (only digits 0 through 9) uniform (random, every number has an equal chance to appear next) distribution, if a 6 was drawn, the expected value of each number from 0 to 9 to follow it is 10%

When we count each of the digits that has followed a 6 in the draw history, we are looking for deviation from that 10% across all 10 possible values. This is how we train that first order Markov chain model to give the result, it is simply a count of the number of times each of the ten digits followed a 6 (or whatever the last number drawn was). This is done against the entire draw history (so for pick 3 evening in PA, that is over 17,000 draws).

They say that the data will converge once there are enough draws to that expected 10% per value.

In addition to the distribution values, I also include the last 10 followers of that number to see if maybe a recent trend is in place that would indicate a better pick than the one with the highest frequency count per column.

So it fits the Markov chain "memoryless" property because it is only presented with the most recent draw. If I were to use all 100 values possible when you look at the last 2 draws, that would become a second order Markov chain... this requires 10x the data, and we know that past draws are not dependent on each other, so there is really no need to go into that extra level of complexity.

Is it a valid predictor? Of course not, as one thing I have learned from these years of study is that contrary to what Gail Howard says, the most of something does not always happen... the most frequent follower in each column is not always the next draw. The hot numbers rarely come out together. What it ends up being is a way to see micro bias in distribution reality vs distribution expectancy.

Has it worked? In the brief time I had actually used it to play, it did bring in one straight pick 3 mid day hit within the first few months.

One thing I have noticed in all of this development time is that I still need to learn how to interpret the volumes of data I can generate.

Why am I including this in the GUI app that is for classification? Because I feel this is an important part of the puzzle. While I have not seen more than 1 straight win on either system, it might be a critical read of both system outputs that reveals a better guess. Plus, the GUI was always intended to be a framework, good for including any number of systems.

Hooking up the update scripts to the kivyMD framework was a walk in the park compared to integrating the classifier and follower scrips... but that is the path I have chosen.

As a dev note, using git to implement proper version control is so much better than my ad hock file naming convention of adding copies appended with _Vx.

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...