hypersoniq's Blog

The 4 week initial cycle of the 2026 "season" is in the books... NOT in the win column... 4 weeks @ $14 per is a $52 expense. Take away the $16 in winnings, net loss of $40.

Tomorrow starts a 3 week pick 3 cycle (mid and eve, $1 straight, same $14 expense each week). Testing follower lag, so a new combo each week for this cycle.

Three weeks from tomorrow begins 3 weeks of pick 5, then the full cycle starts over again.

The PA lottery game images (pick 2 through power ball/mm) on their website are vector based svg files. I will need a vector based drawing app to work with both getting the proper sizes and creating a logo for the app I am building. 

After a few days of research, I have decided to go with inkscape, an open source (free!) vector graphics program for Windows. It checks all of the boxes...

1. It's free!

2. Natively works with svg files. All source images will start as svg files so they scale cleanly.

3. It can export scaled images to rasterized png for use in my app, as kivy has no native render support for vector based svg files.

4. It will work with my Huion Kamvas 16 drawing tablet.

I knew this part would be a learning curve, but better to do it right then hacking together crude images in windows paint!

While coding these last few months, ai have sketched some concepts for a logo. Simple and clean, conveys the purpose of the app and holds the "branding".

Once the graphics are complete, the app should be complete, as all of the functions and output screens have been polished, always keeping the target Android system in mind. The current windows version can be used for the pick 3 cycle starting thursday! I MAY be able to get the first port to Android ready in time for the pick 5 cycle, but realistically more like the 2nd cycle of match 6. (6 week timeframe)

That is exciting because when the app is done I can dedicate 100% of coding time to getting the sliding Markov Chain back test written. This is where I take the time to learn how to better interpret the output of the app. I gave myself all of 2026 to get the app on Android and it may be ready by March!

Bummer to have to replace the Cash 4 Life with the new millionaire for life, because it will not have proper data for years, but the system is designed for such changes quickly and easily. I just have to figure out the game code they will use on their url for the new game and get their logo image for the new game next month.

Progress!

The problem wasn't even a problem on the windows app because I could resize column word wrap away... but this would have been a devastating flaw on Android... jumbled data, rendering data out of the frame with no way to get there...

The issue had several components that needed fixing... first was to dynamically calculate the max actual widest row in each column.

Next was to take the recycle view which already had the vertical scroll ability and wrap the entire screen in a scroll view which allows horizontal scrolling.

With those 2 enhancements in place, I set to look at all of the 6 column outputs and it just works!

Not a bad 2 hours of documentation surfing and trial/error cycles to return to stable. 

Next up is finally the graphics!

I keep draw histories to use for developing systems. I do not view these as a model of the data produced by the mechanical or PRNG process (or in PA, BOTH). I view it as a collection of the results they paid on.

Every single state lottery runs test draws, some even publish the results. I place no value in this data because the state never intended to pay on those results. Power Ball used to publish test draw data.

Up until the end of last year, I excluded PA double draw data (where they picked an extra draw on some nights in the pick N games for a promotion) but I keep it in now because they paid on it. It was quite the project re doing every single history file I had with the new web scraper app. I made 2 versions. The first built the base file, with the header rows from day one of the game history to current. The second simply appends new data to those csv files. This replaced hours of manual copying into the files, particularly if I had not played a game for a long time (like pick 5) and needed to add years of data. Now, there are zero human transcription errors in the data sets, and updates happen with the click of a button... 2 minutes later 14 game histories are updated accurately!

I also maintain separate files for bonus balls like the mega ball and power ball.

Access to the history in or out of the app is a click away, this was the vision realized! 

So when processing this data, I am mostly looking for any micro biases in each column that hopefully points to the next number prediction that will pay out.

There are some that hold zero stock in the usefulness of past draw data, and they make compelling arguments, but I see it differently... there might be a connection, and even if it is coincidental at best, it is better than nothing.

This Markov Chain follower back test script may end up to be the single most complex function I will write, and even if there is no yield, I have honed some skill at trying to solve impossible problems with code, skills that will eventually transcend the lottery hobby.

But, part of the column statistics screen for followers is the last 10 followers. That might be an interesting thing to look at, picking a number that appears more than once in the last 10 followers AND sits highest on the transition list.

That will be another thing to test for when the rolling back test is ready... if there is something to it, there is always the possibility of incorporating highlighting in the app.

No shortage of ideas lately, just a shortage of time to develop each.

Such as using the sorted rows to check for straight hits on pick N games... maybe there is a sweet spot?

It took a bit of research, but it was probably around 10 lines of python code to get it implemented. Aids readability just as it does on spreadsheets.

The last usability issue I need to tackle is text wrap in the classifier columns, and to be honest, I had that issue in the script version as well. This is a non issue in windows because I CAN resize the window and it will re render correctly... this is NOT an option with Android.

Not 100% sure on the fix yet. I tried implementing a scroll view but it did not work. Maybe I need to calculate max row width before rendering and adjust dynamically...

Only has the effect on 6 column games (on windows) and only for classification, but the goal is still Android, so it is solve it here or solve it there... I pick here!

After this gets solved, it is on to graphics!!!!! There is literally zero need to incorporate sound into the app.

That was extremely complicated to add a spinner because I had to create a scope parallel to my screen manager to add it. One change like that rippled through 14 different files... draw update progress bar is now a normal height and not taking up 1/4 of the screen. Ensured that all 3 scripts involved in the update process do not run on the main thread... ALL functions now have zero risk of blocking the main thread! That was an essential requirement for the eventual android version.

Having some thoughts on using the new app to test for Markov Chain lag in the upcoming P3 cycle... that will mean NOT playing the same number for 3 weeks, but instead changing it up each week. Followers were meant to be a per play pick, but lag was never tested in it's previous attempts.

Next up for the app will be to stripe the data rows, making it easier to read, and beginning with adding very limited graphics... mostly just a splash screen logo, an icon and the PA graphics for each game button.

Should not be too much longer before it is polished enough to begin assembling in the docker container for the big Android build!

Ever forward...

My followers script itself is well over a year old. When I originally ran the first back test, it was 100% within Excel.

The idea was simple, loop the script with each digit as the last draw so I would know the top follower of each digit in each position, put these into a lookup table, and count the number of straight hits.

Of all possible "replacement" strategies, this one performed best, meaning at the time, it almost returned enough straight hits to make the imaginary $1 straight per day over the entire history come close to breaking even.

Here is the fatal flaw... you would NOT have known the most frequent followers of 16,000 draws (at the time) in the past! I look at all of the work I put into both the script AND the spreadsheet and then realize I broke the time line by using data from the future to test old draws.

What should I have done? The correct way to test the hypothesis should have been to create a rolling back test... one where older draws are calculated only using data that was available BEFORE that draw... one that indexes and recalculates one draw at a time for every row of history.

It's not like I don't know I make a ton of miscalculations at this stuff, what is important now is to realize when a mistake was made and take corrective action. Excel was the wrong tool, it is better for static analysis.

So with this understanding of why the data I had was incorrect, I can plan a proper back test using the current follower script.

I know that followers need data to start, so I cannot go back to draw #2 like I did in the excel sheet. If I use the first 1,000 draws to prime the data pump, that gives each number a fair chance of appearing 10 times as a follower for each possible digit. That is number of balls * 100 as a generic formula.

I know that the follower distribution returns a list sorted descending by frequency, so the highest follower per column would be something like distA[0].

I know the calculation would be if nextDigitA == distA[0] && nextDigitB == distB[0] && nextDigitC == [0] (for the pick 3) that a correct hit would be identified.

So, if the comparison is held in it's own function, it can be altered to check for other scenarios as well.

I also know that the data inside of the distribution does indeed represent a true first order Markov chain, as the higher the frequency, the higher the probability of that transition. Not perfect, not a guaranteed winner, BUT, the "memoryless" property holds... only the current state (most recent draw) is used to generate the transition probabilities to the next state.

So this now has to be wrapped into a universal script that can be used on a per column basis for any game. Now that I got some practice with structured data return, I can write everything to a dictionary structure and get the output more readable than the old version of the script.

Other metrics could include that when the next draw does NOT equal the current top transition option, how far off was it? Is there anything consistent about those errors? Writing those to a csv file for import into Excel would be the right time to use Excel in the process. If an error matrix is produced, maybe it could yield a "correction factor"?

This is one of those things that will take some time to think about before ever writing a single line of code, but the follower function is already written, just have to build the back test around it.

This is one of those posts where the idea starts to come together for a coding project. The broad idea is a proper back test of the follower script, mixed in with a few off the cuff ideas on what a solution might look like. The back test for classifiers was written once I had gained enough skill and insight to create a sliding test. After working on this idea, I will revisit that one and see if improvements can be made.

I will also print out which numbers hit when a straight match comes up. Curious...

The functions work, the data is properly displayed in columns and the numbers match the stand alone script version for both classification and Markov chain follower distribution. The problem was, the first table was always blank! You could navigate back and return and the data would be there... but what a strange issue, as zero error messages were there to identify the problem.

So I had to do some research and it turns out I was making a correct call, but to the class and not the instance! The moment I saved the change with the proper reference, the bug disappeared! I never had to consider presentation layers and UI timing (and scope) before inside of a single script. I do not know that I would have explicitly learned of that issue without having the opportunity to troubleshoot my own project.

The downside was I did not start on graphics as planned, but the one annoying issue that was persistent since the beginning is now solved!

I also need to make the progress bar less tall on the draw history update screen... it takes up 1/4 of the screen height... but it works. I am now at that phase where I will not accept issues that are within my power to track down and fix. Everything is still Android safe as well. Sticking to the vision!

The current state of the application is 100% functionality, partial UI implementation, zero "branding".

So there needs to be full use testing so that there are no surprises. In addition, it is time to think about generating graphics for the app. I already have a place in the directory structure to hold graphic assets.

There is also the need to do with the classification output what I did with the Markov follower output, which is to run game classifications and compare line by line to original script output.

Because of the high level separation of concerns present in the framework, each area can be addressed without risk of "breaking" the other areas. Back end is separate from UI which is also separate from the logic section where the back end and UI components are "glued" together with function call builders and game meta data.

So far, the entire project was assembled with IDLE, the IDE that ships with standard Python (no PyCharm or VS Code overkill), also the .kv files are created and edited with Notepad++, a HIGHLY recommended free tool for ANY type of coding, from C to web dev (CSS and RUST come to mind). It is also great for git MD (mark down) files.

It is launched from the command line (I use Windows Power Shell) until it is time to wrap the whole thing as an EXE and create a desktop icon for it.

For the use tests, I need to take notes on different areas if changes or improvements need to be made.

1. Back end - generic functionality and output of the core functions of history update, classification and Markov Chain Followers.

2. UI/UX - does every screen look and act like a unified project? Here js why I chose the kivyMD extension as the use of Google Material Design starts off with a pleasant interface out of the gate. Also, the classifier script runs longer than the follower, perhaps a spinning graphic to indicate "processing" will be better than a user staring at what looks to be a frozen screen...

3. Logic - functions are built correctly, game info is consistent.

4. Graphics - no need for overkill, but if a screen looks like it would benefit from graphic elements (like the choose game screen using the small graphics for each game from the PA lottery Website or the project logo), they can be imagined, created, implemented and evaluated.

Compromise has already been leveraged against the original vision... "user settings", "All Neutral Quick Pick" and "ball view" have been scrapped because they were not worth the extra time and effort for what they returned.

So still plenty to do and learn, but it is honestly much more rewarding to tweak a functional app rather than the skeleton of an idea!

From the outset, the expense is known... $728 ($14 /week)

That works out to 5 cycles of all 3 games plus 2 weeks of Match 6 until the end of 2026

Each 10 week full cycle is 4 weeks of Match 6, followed by 3 weeks of pick 3 (day & eve) and 3 weeks of pick 5 (day & eve)

So, knowing the expense, the scenarios that could make the entire year profitable...

5/6 on the Match 6 = $1,000 (pre tax)

Any 2 straight pick 3 hits = $1,000

One single hit on the pick 5 = $50,000 (pre tax)

Of course, the Match 6 brings to the table a potential jackpot that starts at $500,000 (pre tax).

So the goal is pretty simple... learn to interpret the data I am generating with each cycle to get more accurate.

Also, any extra play such as MM or PB will wait until that $728 expense is gone. May not be the best plan, but it is easily affordable and offers chances at prize levels other than $500 on a straight hit for pick 3, which was the majority of last year's play.

Since I have over a week left on the Match 6, I plan to run a back test on the lab (script) version of the Markov Chain follower program. The data is exact between the app and the script, and the lab has it's own copy of the data files.

Test 1. Check for lag by deleting the last 21 draws and running the script, checking the highest output as it prints for a straight hit over the next 21 draws.

Test 2. Using the 10 most recent followers that outputs with each column, see if that adjustment appears straight anywhere over the same 21 draws.

By deleting draw history, the test has zero cost!

Also, as a new year thing, I am going to begin back testing jackpot games as well. I usually stuck to back testing the pick 3 because I would not mind if I missed out on a $500 win, but without testing on the other games, how do I make improvements?

I will go back 10 times, so the test will cover 210 draws, and I will repeat it on the pick 5.

Then, when the Match 6 cycle is complete, I will run a similar test on that game.

The classification portion will be used as a reference, so the follower data is not picking all colds. Guess we could say that will be the third test....

3 picks...

1. Raw frequency of the followers

2. Followers guided by the most frequent of the last 10 followers

3. Ranging for the pick based on placement in the Hot, Neutral and Cold table.

Whichever method works best in the back test will be carried forward for the first cycle of the pick 3 and the pick 5.

Hoping this will be the year I can do better than a handful of pick 3 straight hits...

I am old (therefore old school), I thought the best way forward with graphic elements (like the logo, icons and button graphics) would be nice and small .png files. Enter svg (vector vs. raster)... since I am yet unaware of the display sizes, if I create vector graphics, they will have no noticeable compression artifacts at a wide range of sizes.

Of course, most of my graphics programs are raster based (krita5, apple proCreate) so that is where I shall begin my next part of the learning phase.

Also, going file to file and making sure each python file has a docstring (a comment beginning and ending with three ") that describes what the file does. This will help later as there are tools that can help create skeleton documentation by parsing docstrings. I remember Java having a similar mechanism.

But this division of work, first ensuring functionality, then worrying about how it looks, was the right move for sure. There is not any code that is confusing in there, and appearance is confined to the UI screens and their matched kv files, the logic is sound and not involved in the "look" aspect.

At this point, I should probably plan a way to back test the Markov chain distribution. That will not involve the gui, and instead remain in my script "lab" sandbox. I spent so much time getting things to work, but not enough time learning proper interpretation of the generated data.

That back test should probably answer the following questions...

1. At face value, how many times was the highest frequency follower a straight match for the game? (Will start with pick 3) as a simpler count, the first element of the distribution is the highest frequency, so did column1 match distOne[0] AND did column2 match distTwo[0] AND did column3 match distThree[0]?

2. As a total system, where did the matches come from most? I already know it is not the highest element most draws... so where in the dist list did they come from? Such as distOne[4] AND distTwo[3] and distThree[8]... building up a matrix of hit distribution.

3. What about lag potential? Did the highest frequency in the chain match somewhere over the next N draws? Now, maybe not, but since we are looking, may as well look everywhere.

Why this back test now? Because it is better to move forward then stare blankly at half finished ideas. Also, I feel that based on the data so far, this Markov chain strategy will be helpful with the vertical sum concept I am cooking up.

As for now, the priority is the app... after graphics creation and implementation, the app will be just about done. But I learned that if I put a next project in the back of my mind early, the solutions tend to start leaking through rather than starting from scratch.

Between the processing steps available in the app and the draw history update feature, this project is already worth the effort, even if it never wins a single draw because I have the opportunity to upskill from writing scripts to pro grade software frameworks. When I saw how fast this project came together because I followed industry best practices at the script level, continuing the same practices at the app level really solidify the concepts, and I would not be starting from just ideas when I branch out into something NOT related to the lottery.

On that point, lottery data, even though nothing ever truly works out, is a long time hobby and allowed me to power through the challenges because I was motivated... not so much with most of the "To Do List" tutorials out there.

With a 4 week cycle, the Match 6 is currently at a net loss of -$26. The hits amounted to $16 so far. Playing each week separately regenerates 2 new QP lines.

A combination of follower data and classification data was used for the first pick.

One more week on that M6 combo and we get a first look at the pick 3 cycle (3 weeks) and finally 3 weeks of the pick 5. That will complete the first full 10 week cycle.

Now that the app can be used for displaying the data (and updating the draws), no more running different scripts!

Once it looks a bit better I will put some screen shots up.

BOTH the classifier function AND the follower/Markov chain function work! They display the data in tables, and then can drill down into the column stats view with the additional stats collected!

When I started building this, I designed from the top level screen down each button path...

The main screen has 2 buttons, "update draws" and "choose game"

I went down the update path first and got that 100% functional.

The choose game brings up a collection of buttons representing 14 current PA lottery games. When you choose a game, it takes you to a screen where you can choose to calculate classifiers or show followers.

The next screen for each displays the column headers and the aligned column data. From there you have 2 choices... go back or display the column statistics... the stats screen shows the stats unique to the chosen processing method... and it does it correctly!

Every screen has a back nav button.

I went through multiple games to ensure specialized features worked (like the bonus balls in PB, MM and Cash4Life)

It is not perfect yet, but the thing just works!

The learning curve was a bit steep, but not as bad as I thought. Having done some Ruby on Rails tutorials a few years ago helped with the MVC pattern concepts.

Because I kept with the mantra of make it work first, then make it look good, I know how all of the parts fit together, so any changes to ball matrices or new games can be easily added, and if a game gets discontinued, I know how to remove it. As I learned more about kivy, the screens near the end look better, so I will have to make sure the new concepts get propagated to the earlier, more utilitarian look of the starting screens.

I wrote the follower script over a year ago. It went through many tweaks to get it modular enough to use in an app... even before I knew what shape the app would take.

I am just super excited that this went from project folder last month to functional prototype application now!

The only functional change I need to make yet is to put my frequency sort back into the classifier output... then the rest will be cosmetic changes, creating and adding graphics and ensuring there are no more edge cases left to test for.

I will say that one decision I made was to NOT have a settings page where the numbers could be tweaked... that is best left to the original script sandbox. That saved on generating another screen that was context sensitive AND I did not have to sanitize user input.

Every screen can make use of Google's Material Design elements, so getting a unifying theme together should be straightforward.

Up until today, I was faced with the follower output working but the app crashing when trying to view the column stats for classifiers... that was fixed on the python side by reading the data shape for the script output and matching it to a specific display format (using kivy "card" widgets instead of generic display areas).

The end to end tests were a success! No idea how long it will take to make it look nice and to incorporate graphics, to properly document and to get ready for the Android port, but I have a gut feeling that I will hit my 2026 goal of having this app on my phone before year's end!

Just had to celebrate the functional win! 😎