hypersoniq's Blog

So, I have learned that every single game history comprises  a discrete uniform distribution. Testing with a Chi Square Goodness of fit test verifies that whole histories to single columns of a smaller sample pass this test. Bottom line, whatever the draw method (ball machines or RNG), the data is random enough.

Not only are past draws independent, but in the case of pick N games, the positions are also independent. Think about that... the pick 3 history is completely different for each position. I can see this easier with the new classification divisions that highlight where each neutral exists in relation to the median. Looking at pick 3 data shows 3 different histories, with different statistics for each. If there are cycles in the data, they most certainly do not happen at the same time. When follower frequency is measured, the 10 most recent followers actually prove to be better at zeroing in on a specific next digit than the whole Markov Chain display... but not always and not predictably. The shapes described by the classification are different with each position .. some have true median plateaus, while others have zero numbers at the expected value, and can tilt in favor of an above median or below median neutral band. This is the entire reason that older systems (and current ones as well) seem to have that "synchronization issue", where a system might pick 2 of three correctly, but be way off on the third.

Based on the above, it would be easy to pack it all in, I have certainly tried. I have taken many lessons in spreadsheet use and programming enough to say it was not a wasted journey... but it could just be that the journey is the thing... ever chasing that elusive solution to the impossible problem that keeps driving development and refinement.

The goal has never changed... make one pick based on the past draws. The methods have evolved, the data collected has certainly changed but the goal is still the same.

I think that learning to better interpret the data is that elusive next target. I get that feeling that statistics holds the answer, but I am still falling short on asking the right questions. I remember thinking the same thing over 20 years ago when I created my first draw history spreadsheet...

As I focus more attention to the Vertical Sums, there is a specific work flow that comes to mind... using a spreadsheet to design and experiment with the parameters on one page, and designing the output on another. This was the same process used early on to create both the follower and classifier scripts.

The plan for the vertical sum sheet will be to experiment with the sample size N and the number of rows to sum k.

Since we are working without guidelines, we will have to find them.

The concept would be to pick a sample size that is not data starved, but not so big that it loses volatility. Here solving for k first, and then making the sample size N a multiple of k makes the most sense.

Here we will be applying an interpretation of the "rule of 30". Since we know the distribution to be both discrete AND uniform, a value of k set to 10 seems a logical starting point since the pick N games have 10 digits each. And for N, we apply k x 30 for an N (sample size) of 300.

This would scale with games like Match 6 where k would be 49 and the sample size would be k x 30 = 1,470.

That is not a magic formula, but you have to start somewhere.

The basic idea is to roll the sums forward one draw at a time and record that sum. When you have enough sums, take the average of the sums (or alternatively, record the most frequent recurring sum) and then sum the last k-1 (9) draws and compare it to the average (or mode) and simply subtract the last 9 from the average (or mode) to get a guess. At the spreadsheet lab level, it is possible to record both the average sum and determine the most frequent sum and compare the accuracy.

While not as robust or complex as an AutoRegressive Integrated Moving Average (ARIMA), it still functions to analyze the time series lottery data from it's own past values.

This first sheet is where the design decisions can be made.

The second sheet will be used to experiment with what data should be output. This is where we would record the average and mode result of all of the k sums in the N sample size. Any other relevant data can be placed here.

When done, sheet 1 will help describe the per column script in Python, while sheet 2 will be a model of the output.

In order to fit a Vsum function into my app, I need to determine the output based on the framework... the table view would contain the 30 sums in the 300 sample size, and the stats card view would contain the average and mode of those sums and also calculate the last k-1 leaving you with a pick for each column.

When I designed the app, it was with pre existing csv files that can be updated. I also included a cache folder with the idea that maybe in the future I would need to generate a temporary file. This might be a use for one! A csv file that could be generated for display, then deleted when exiting the app... this way switching between functions for analysis could be done to compare data with the followers or classifiers and not need to be completely recreated.

Here is the best part... developing first as a universal stand alone script means I never have to touch the stable code base of the app unless it proves to add value. If the spreadsheet stage fails, Then a script never even gets written.

The hard part is done. I have created a portable framework. I can get back to exploring ideas again, only now with a proven work flow and targeted outputs. And if something does not fit the table/stats output, it can stay a single script. I cannot even describe the joy found in this hobby by automating updates. The whole GUI learning experience was worth the effort... even if that win is still elusive.

The concept is easy to imagine, but what would it look like as a function?

A sample size would need to be determined, then a step run over that sample would give a table of N vertical sums... but how many? One per ball of the game? A fixed number from 3 to 10?

You would need, for example, 5 number sums in a table, but also the sum of the last 4 games... in the framework, that sum would be placed on a stats card on the screen after the table, along with average sums for the sample. The thought process being average sum of each 5 in the sample minus the last 4 is your pick.

Time will be needed to get an idea of the sum size and sample size. But that is the basic premise for a start.

PA has yet to put up a results print page for Millionaire for life. They removed the link to the print pages (one year at a time) from the results screen, but still update the draw data daily.

Going to write a scraper to grab the game titles from ID 1 through 100 to try and find it. If there is none, then Millionaire for life will be skipped.

The process of splitting the N range in the app was easy, and is already working on the windows version, pushing to android on Friday, after the removal of the Cash 4 Life.

The N range needed a split because they make up 70% of the data, and a split at the median was a natural choice. This represents the size and shape of the column distribution without the express need to graph it.

Also noted in the search for M4L data, they do not have a print page for their cash pop game either. Not that missing cash pop was a concern.

Here is hoping that the print pages there keep going, because it is already lame enough that they do not have an api...

After completing the manual tracking spreadsheet for 21 days of the pick 2, one thing is fairly obvious, the "lag test" is most certainly NOT a factor. I will include it in the big back test, but I think it is time to shift gears from weekly play to a return to daily play, which will reduce the expense from $14/week to $8/week. So given I am 8 weeks in with a -$96 result so far, this will reduce the expense by $264 and drop the projected cost (past draws included) to a total of $448 for 2026, or the balance of future play down to $352.

I will also split up the Neutral classification into 

NA = neutral above the median

N = neutral equals the median

NB = neutral below the median

That gives 5 categories:

H>NA>N>NB>C

Consideration of the draws out is also helpful to determine where these numbers come from and how to use each of the screens in the app to get a pick.

So the Cycles will remain mostly the same...

4 weeks of Match 6, covering 16 draws instead of 28.

3 weeks of pick 3, covering 12 draws instead of 21.

And 3 weeks of pick 5, covering 12 draws instead of 21.

Follower data, particularly the single appearance of a digit in the last 10 + classifier information, including draws out and drift from the median = the new direction for play... saving money AND having a new combo for every drawing.

The script for the back test will be the largest single script that I have ever written... so that will take some time, but at least I know what information to collect.

Saving money and diving deeper into the stats is the next best step, as refinements can happen between individual iterations rather than on a weekly basis.

None of this possible without the framework I have built... had I still needed to update draw histories and run 2 separate scripts, it may have been dropped already as too labor intensive. THIS is why the app was built.

Tonight ends the week long first cycle of the pick 5. First solo shot at the pick 5 will be Thursday.

A few data points that I wanted to capture were left out... the most recent appearance of the winning numbers, the median, AND, a new metric that will be worked into the app... a division of neutrals into NA and NB, the last letter indicating if the neutral frequency is Above or Below the median. IF the neutral frequency is exactly the median, it will stay N.

21 draws of each (pick 2 mid and eve) should be enough to hammer out what data to write to the csv and what data to output at the end of the test.

As a prelude to doing a major back test on the data files, I think I need to manually work out the process of exactly what to write as output to capture the relevant information in a useful way.

The pick 2 should be the easiest way to start. Using the windows version of the app (where I have direct access to the csv files) I will record, then remove the last 21 draws, running the follower for each draw and recording the results in a blank spreadsheet. Both day and evening variants. What I am looking for is what exactly to record and check. This way I have a controlled environment to see which data is important to record and which can be left out. Taking notes on the manual process at each step will define the algorithm that will then be used to write the script.

I will also be looking at the classifier output for each step. Manually checking for any correlation between functions, though this raises the complexity, it is one reason I put both functions into the app.

This may take a few days to figure out, but then the proper back test algorithm can be assembled.

What are the target metrics?

1. Did the direct follower output match the next draw? If not, which frequency level did the next draw come from?

2. Did the numbers in the next draw appear in the list of the 10 most frequent followers?

3. What difference in position did the next draw hold on the classifier output, and how many draws out were the winning numbers?

4. IF a draw was correct on the follower list, what was the inter quartile range on the classifier for each digit? Wider on a match? Narrower on a match?

The coding is not always as easy as it sounds. The classifier took a year to get working, and the first follower script is over 2 years old now. But it is not a race... better to be correct than quick. I do feel that this hobby keeps me more involved in learning various things about creating software to solve problems than college ever did.

Since it will be a swap, certain things will have to be done to remove the data for Cash 4 Life and introduce the Millionaire for life game.

1. Obtain the new image

2. Update the config.py file to remove the PACashForLife.csv file and replace it with the PAMillionaireForLife.csv

3. Change the game metadata for the name, Icon, number of draws for the sample size (870), high ball (from 60 to 58) and also change the nonus high ball from 4 to 5.

4. Rename the button on the game select screen to match the new game.

5. Introduce the logic that will disable the "classification" script until the .csv file contains 870 draws. This will be a wide universal change that checks the .csv row count with the value in "classifier draws" for all games.

6. Determine the new ID number for the URL query parameter to select the right data to scrape.

 

I am also considering placing a Quick Pick button for each game, it will go in line with the classification and frequency Analysis buttons on the game action screen. A true QP generator that will display the QP appropriate for each individual game when pressed on that screen.

The first step of all is to make the above changes to the windows app. Then simply rebuild and update the Android app. Also adding an icon to the windows desktop for a 1 click launch of the app. Still plenty to work on, but the look and feel of the UI on both platforms seems solid!

As tonight is the final sale of tickets for the Cash 4 Life draw, I have decided to stay on budget for the week and skip it.

I did not ask for a new $5 game, the $2 C4L was fine exactly how it was.

I liked all the history available (10 years) when I did have a go at the game. 

I will try this game once, on July 12th, 2028, as the night before will hit the 870 draws required to run the classification function in the app. By then hopefully I will have learned how to read it. 

They can do without my $5 until then.

Draw 1 mid day had 4 of 5 numbers, but none in order.

Draw 1 eve had 2 of 5 numbers, none in position.

Draw 2 mid had 4 of 5 again, one in position.

Draw 2 eve had 4 of 5, one in position.

The cluster of numbers would only matter if I had also played boxed, 3 near misses... however, the pick 5 has a $1 minimum bet, so going with straight only to stay @ the $14/week budget.

I suppose we will see if there are missed box hits maybe a redistribution of the available budget may be in order (play st + box for 3 weeks and cut out 3 of 4 weeks of the Match 6, which seems to be hit by everyone in PA but me...) then the full cycle would include 3 weeks "off"... but there would need to be more than 1 missed box hit to justify anything like that. It does pay $425 on a 120 way box.

Still interesting to see 4 of 5 three times in 4 draws...

Since there are 3 weeks, a different strategy will be applied each week.

Week 1: Taking the Markov Chain follower direct result, using the classifier as a tie breaker on equal frequencies.

Week 2: taking the 10 most recent followers per position, and finding the one highest on the list in the classifiers for each position.

Week 3: taking the digit in each column that is simultaneously highest on both classifier and follower tables, that also appears on the 10 most recent followers list.

They could all be way off, one may get closer than the others, maybe a dumb luck coincidental win... I should have mixed it up with the match 6 and pick 3 cycles, but I was too busy making the Android app work.

After this P5 cycle, I may consider going back to playing the games on days I have opportunity, which would reduce plays to 3 or 4 days a week and directly reduce the cost. But that depends on the ongoing lag test.

The idea I have for the classifier as a back test might finally help define that "churn", or how the numbers are random, but the frequencies are closer to the same. This would involve tracking the average time it takes for numbers to transition from hot to neutral, from neutral to cold and also from cold to neutral and neutral to hot.

The app was not the end game... only the beginning of understanding and interpreting the data it produces.

After the last draws of the pick 3, the tally stands at -$82, adding round one of pick 5 tomorrow takes that to -$96.

There is still that 1:1000 chance on the last mid and eve draws in the pick 3 cycle today, but that has yet to work into a win. One or the other hitting today would give me back the $82 spent so far and fund the "experiment" into September! A hit on the pick 5 would refund the money spent on the lottery over my entire play history! (I had plenty of "off" times, sometimes spanning years, and I am cheap, and don't always lose)

I have had better luck over the years on the pick 4, now that the app can handle all 14 games (except cash pop, they can keep that money grab) I may also switch up games in the cycle pattern... maybe a cash5, pick 4, pick 5 cycle?

5 days away from my first major app update, removing Cash 4 Life and replacing it with Millionaire 4 Life. I have to put all of the parts together and test on the windows app before pushing the Android update, including deactivating the classifier button on that game until there are 870 draws.

While this project bas been a rewarding learning experience so far and a win would just be the icing on the cake, I am about ready for dessert!

Extra update... curiosity got the best of me. I tried putting the app on my decade old galaxy note 8... it works! Slower, but not unreasonably so.

The first reason was validating the data, the check for the same exact data display on both platforms was an easy confirmation that this works on Windows and Android.

The main goal was to gain experience in creating an application that was truly cross platform. There are no missing or watered down features when going from laptop to phone, it is line by line the same code!

And with the ability to view both programs running side by side, I can now view both classifier AND follower data at the same time!

So, with another opportunity for a coding day, I was taking notes since it worked on possible changes, mostly in UI appearance... nothing major, the biggest thing will be centering the game select buttons on the screen, a one line fix in the game_select.kv file.

Then I can start planning the most massive back test ever on the Markov Chain Follower part... once I see how it would have done, and find hints on how to better interpret the data, I can apply directly the concepts to the idea of vertical sums in pick N games. If there is anything to the vertical sums concept, it can be added as a new function right in the framework!

Those are the first 2 coding goals now that my entire 2026 plan was completed so early. If any ideas come up for how to better apply back testing to the classifications, that will be figured out and built as well. Also going to add jackpot games to back testing, that is new as well.

Now I have a clean work flow for projects... start on windows where debugging is so much faster, then port to Android where it becomes an instance of building from the working windows blueprint.

But tonight, after the evening draw, I will run the app for updates on the phone, and generate the pick for the first week of the pick 5 cycle... no laptop required!

The diagnostic prints proved instrumental in zeroing in on the issue, the Android path join was being read as a string division error, so a change to the correct path for Android solved days of frustrating troubleshooting.

Updating works as well, so now the start of the pick5 cycle will be done from the phone!

There will undoubtedly be a few minor cosmetic changes as I take time to go over every screen with both the windows and android versions, but everything is holding up well. Hard to believe my Python app, which uses Numpy, Pandas, requests, beautiful soup 4 AND reads and writes to csv files is alive on 2 different platforms...

I was giving myself ALL of 2026 to get to this point... got there with PLENTY of time to start the other projects I have planned.

Also nice to know that my OLD MSI G62 Apache Pro is up to the task after all of these years. I bought that to start going part time for a degree in 2016... graduated in 2023 (not exaggerating the part time aspect), and have always used it to practice the Python coding craft.

Cannot update to windows 11 (too old, according to Microsoft), 16GB of RAM and a 1TB SSD... powered through building this app inside of a persistent docker container from the WSL/Ubuntu Linux command line, one big 6 hour build to start, a smaller 3 hour build when I realized I did not need a 32 bit version of the app, dozens of troubleshooting rebuilds (about 10 to 15 minutes each), side loading the APK onto my phone from a USB cable, running ADB in windows power shell... all on a completely unknown (to me) tool chain that included kivy, kivyMD, Docker, WSL, Buildozer (a tool for packaging python apps for Android, P4A, a tool for running Python apps in Android's OS, Inkscape for the graphics... so much stuff to get a handle on all at once., and now I have the app right in my hand... crazy!

 

Takes about an hour when installing a missing component. This time I loaded the functions with debug prints, all tagged with "Sleepy_Hollow" so they can be filtered out from the thousands of lines of output in an unfiltered run of the Android Debug Bridge.

What it will display is

1. Confirmation of entering each function

2. A 5 row "tail" of the data imported into pandas from the csv files

3. Confirmation of ending the functions

4. The exact return values

This will zero in on the issue

If it never enters, then the issue is isolated to config.py

If it is receiving malformed data from the csv files, then that will have to be addressed.

If it is outputting malformed data, then that issue will need to be addressed.

The data was left stale ( to 2/5/2026) so the updater can be tested. So running the functions then updater and functions again will test everything in one run.

Amazing what a few days away from a project like this can do for clarity.

Ever forward!

I was almost there, getting error messages that made no sense, string division in a script that literally has no division in it !?!?!?!?

The program does not crash anymore, because I now have the csv files copied to the correct directory on first run only. The error messages are properly read even though I wrapped them in a tuple to return properly... the error just makes no sense.

I finally configured docker to keep a persistent container, wrestled with the kivy buildozer.spec file (the mother of all configuration files) and got a crash course on using String Search in Windows power shell, which is much better than running the android debug bridge from an elevated command line (that's just running CMD as administrator)

The maddening part is the app worked except for reading stale data... fix that and the functions break... I even asked the LLM about the error when the stack overflow search returned nothing useful (nor did the kivy site documentation), and the LLM had no idea... perfect!

Won't have a chance to get back to it until at least Wednesday, and then the plan is to add more diagnostic print statements to each python file that stands between game select and game action screens. Maybe the kivy discussion on discord or reddit may turn something up... but usually if it cannot be found on stack overflow, then it cannot be found... hey, at least the Windows version of the app is 100% functional!