hypersoniq's Blog

Given that just about every single thing I looked at with regard to accurately predicting numbers over the last 20 plus years has come up dry, it is time to change the strategy.

The new plan, as covered before, is to take on the jackpot games in alternating weeks. The old budget was $14 per week every week, so that was $28 in a 2 week span, this new budget, which will include adding on the multiplier and double draw for power ball will cost $12 one week and $10 the next... $22 every 2 weeks, already a $6 budget cut!

The Match 6 was hit last night, that was to be the switch point.

I know I cut back to 4 plays a week and cut the budget to $8/week but, that was not really working out well.

So for this first week, taking the $34 won on the Match 6, going to play both games (PB and MM) for an initial startup cost of $22, the $12 remaining will go to the first alternating week of the PB.

Since the initial system of classifiers was the basis of play (pick 1 combo and play it for the week), that will continue... one combo for 3 PB draws or 1 combo for 2 MM draws... that means I only need to hit the kiosk once in a week. The Markov Chain Follower data will be used to break any ties, but this iteration will focus on classifiers at transitions. 

Because the app has been fixed for the truncating bonus ball table issue, it is entirely possible to make a pick on the go, but because I have windows and android both running, picks can be made with both data screens open at the same time.

Looking at the alternation, the annual cost would be $572. That is much lower than the old budget that had an annual cost of $728. The cost of playing both jackpot games every week would have been $1,144... hence the alternating weeks.

The plan is to first check the results to see where in the tables the winning numbers came from on the classifier table and THEN update the draws after the cycle completes, that way it can be seen which areas the winning numbers were drawn. Follower data becomes irrelevant after the first draw.

The big back test is going to be way more complex than I originally anticipated, the csv file generated will be massive, as one single row will have data from all of the classifiers AND all of the followers... that would be 40 cells just for the pick 2, add another 10 columns for the stats... PB would have a minimum of 200! This means writing the csv and ingesting to a database table, because that will be one busy spreadsheet! Wide for the jackpot games (many columns) and tall for the pick N games (many rows). But it is the only way to get an accurate back test, because the entire output of both functions needs to be captured on each row.

Now if I separate the functions, that would be a bit more useful as the individual functions can be back tested, then the tables can be merged later. Might go that route.

It all may prove to be a waste of time, but I got this far. Every software engineering goal was met with the app, except the winning part... that very well be truly impossible... but it can never be said that I did not try...

I was here when they were taught, there was one thing that always struck me as odd, that is the confusion when encoding numbers within other numbers. The heart of the vtrack system is essentially encoding each pick N digit AND it's mirror into a v number. 

The original encoding...

v1 = 0 and 5

v2 = 1 and 6

v3 = 2 and 7

v4 = 3 and 8

v5 = 4 and 9

When looking at something like v111, it leaves 8 combinations... 000, 005, 050, 055, 500, 505, 550 and 555.

I always found that to be a bit confusing.

My modest suggestion for a new encoding...

vA replaces v1

vB replaces v2

vC replaces v3

vD replaces v4

vE replaces v5

Now instead of v555, it would read vEEE, still representing the same set of numbers: 444, 449, 494, 499, 944, 949, 994 and 999.

To be fair, the whole concept lost me on "mirror states" and numbers that "travel", but if I were to revisit the initial encoding idea, it would be after changing the numbers to letters as outlined above. The other reason vtracks never resonated for me is that it involves playing multiple bets for the same draw, but it was as wrong at prediction as any other system... the entire concept of lottery as entertainment loses it's appeal when the budget would get high enough that one would NEED to win to cover the losses.

I lost ALL of my vtrack spreadsheets when the first laptop bit the dust... never replaced them.

Where I left off was replacing all of the complex encoding formulas with a much faster lookup table, that allowed applying the encoding rapidly across entire draw histories. There were patterns to be seen, but they were not accurate predictors... but what if they could help identify cyclic regimes and map out their changes? Hmmm...

As of last night, the rolling 6/49 is at $5,860,000. This is a slow roll, as the jackpot does not go up much with each draw. The first ticket played this week matched 3/6 ($2) and 5/18 ($5).

Over the next few weeks I will stay on the M6 cycle until it gets hit, then it is alternating between PB and MM for the rest of the year. If dumb luck is a component, may as well go big. There is slightly less frustration involved when a one in 200+ million odds ticket misses than not even catching a single 1 in 1,000 after multiple attempts.

Fun facts:

On the power ball red ball, the longest out is 8, which has last been seen 96 draws ago. Classification is NB, or the Neutral Below the median. It is the lowest of the 7 NB numbers. In the followers, it is 18th on the list.

On the mega millions gold ball, the longest out is 15, which has last been seen 105 draws ago. Classification is the coldest of the cold numbers. In the followers it is 16th on the list.

Today's coding will involve removing the white ball list truncation discovered earlier. Already fixed on windows, just need to push the update to the Android version. Will also take another look at finding the single source of truth for the PA draw histories so Millionaire for Life can be added.

On an unrelated note, on 3/9 the final payment was made on the 30 year mortgage! Our 31st anniversary is coming up next week as well.

While the app was meant to present the data, not necessarily a pick, certain interesting things emerge from the statistics.

Here it is noticing that in a sorted order, the samples for the white balls in the bonus games PB/MM AND the regular non replacement games Cash 5/Match 6/Treasure Hunt all have something in common...

Variance, when plotted, looks like the vertical cross section of a bowl (a U shape). Higher at the first and last columns, which is likely due to the constraints of sorted order. While the variance is not exactly the same in each game, they all exhibit a similar bowl shape, like an inverted bell curve.

Not sure how that would help with a pick, but the shape persists across all of the non replacement games. The bowl is not symmetric, both power ball and mega millions have a slightly higher variance in the last column vs. The first.

Continuing to study the stats for further such information...

Been thinking about the current plays... did not get any hits outside of the Match 6 so far, and they were small wins.

After calculations and analysis over a few decades, my conclusion is, though it MAY be possible to use computing power to help find winners, I simply lack the ability to do it! I don't see patterns because there are none! The Markov chain would have found them applied to followers... in any other data, the steps taken would have been rewarded with results... identifying trends in other domains yet ending up with nothing useful in random data after multiple attempts using every statistical technique ever learned might just mean it is true, this is really an impossible quest.

That being said, I did learn a great deal of software engineering thanks to this hobby. I did not spend months hand crafting an application that works on both Windows and Android not to use it...

It's time to change focus...

Time to scrap the current cyclic play scenario. If my app would ever be a coincidental match to a number, that is all it would be... coincidental. So, if the whole premise is disproven, impossible to pick a single combo for the next draw in any game, be it RNG or ball drawn, then why continue to play for peanuts?

So a new strategy emerges... alternating weeks on PB and MM... if it is dumb luck anyway, even the base jackpots with another winner would be enough to retire comfortably... why not just skip over the small games and just go for the big ones?

New plan, alternate weeks of PB (3 draws, $12 total with the add ons) and MM (2 draws, flat $10). That comes in under the price of the old system which budgeted $14 per week... in 2 weeks it is $6 cheaper!

If a jackpot starts climbing then pause the alternating games and stick with the higher jackpot.

So, one pick per draw, taken from the data in the app. I already know the follower data is not helpful in the selection process, so it will be based on the transition areas from the classifier, using follower data as a tie breaker... once I patch up the app to display all of the rows.

So that is the new plan for the rest of the year. NOT playing both games at the same time (even though a weekly budget of $22 is not unreasonable), but alternating until jackpot levels begin to diverge. However, I will take $22 out of that $27 Match 6 win and start next week with BOTH games.

The vertical sums went nowhere, because on the surface it ends up being a pick from 10 draws prior, not back testing enough wins to justify playing. When applying the averages or modes, there were draws where the value exceeded the 0-9 range, even with a "lottery math" tweak, back tests were not profitable at all. That will not make it into the app, but it is interesting trying new ideas once in awhile.

There is still the path to be explored with SQL, but I don't know which direction that may take.

I am not able to make one thousand to one odds work, so let's go for a few hundred million to one... maybe I AM an idiot...

When you create an app and you are the only user, bugs might go unnoticed for longer. The app has 1 major flaw at the moment, it cuts off the data rows to match the shortest column... not noticed in 11 of 14 games because they display properly.

The obvious cause... in either the classifier function or the follower function, a second run of the function is made for the bonus ball games, this is to have the right statistics appear for the range of balls, such that in the power ball the 5/69 will have a different expectancy than the 1/26. Well the issue is ALL of the columns are cut off after 26 rows... the stats screen still displays the correct information, but the table is cut off in ALL columns to the shortest row, the bonus ball.

To trace this, the flow of information needs to isolate the exact moment where the data is combined and written to the table.

It is not in the functions, they run twice.

It is not in the logic part of the screen display.

It is in the "game factory", where for bonus ball games it sets up both runs. I would not know this if I let AI write the code... this is why the project took a few months instead of a few hours.

The fix will be relatively simple, in the second run, pad the rows so it matches the larger row count of the white balls.

That of course means fixing it first on the windows side, then pushing the fix to Android.

Having been focused on the pick 3, pick 5 and match 6, I would not have noticed right away. All of the single runs work perfectly... the match 6 pads shorter columns with (none, none) on the followers and zero counts on the classifier.

That being found when looking at the Cash 4 Life screen while trying to figure out how to find the data for Millionaire 4 Life since the lazy PA lottery did not make a page for "year at a time" data. It only had 4 rows in both functions. Then checking power ball and mega millions, it was then obvious that the data cut off at the end of the bonus ball row.

At least the updater still works for the 13 remaining games, they did not screw that up...

PostgreSQL 18.3 does now run on my 10 year old laptop! Had to first uninstall PostgreSQL 11, the version I used in school. The latest R studio is now in place, as well as updating the python libraries to include the one for interacting with SQL and Biopython.

On that front I have some project ideas already...

1. A dashboard that tracks research and clinical trials for tackling type 1 diabetes (T1D).

2. An app that will compare samples of white blood cell components and beta cell components from datasets of people with and without T1D.

Nothing on the edge, just a place to get started... a "Hello Bioinformatics World" project.

Got PostgreSQL 18.3 installed, as well as the library that allows python to interact with PostgreSQL. LextEdit is already installed. Next day off will be connecting everything via ODBC (open database connectivity) drivers and creating tables out of the draw history CSV files.

Also got the most recent version of R studio set up. Will have to explore the latest packages (like python libraries) to get it set up properly.

Still amazed at how much modern software will still run on this 10 year old laptop!

Also had a thought... since I have so much time working with noisy chaotic data with the lottery hobby, an interesting path for non lottery related development would be bioinformatics... to that end I have installed the Biopython library.

Deciding to get out of week 3 of the pick 5 to chase the now $4,650,000 Match 6 jackpot was worth it. On the ticket, 2 of my numbers picked were drawn, then 3 on the first quick pick line, and 2 on the second quick pick line. The 3 on one line was a return of the $2 spent, and the 7/18 is worth $25.

That was running the top of the Markov Chain Follower report... 2 of 6. That could have done better, but one takes what one is given. I would have had 3 of 6 if I viewed the classifier report and ran the NA line, which is playing the last "neutral above the median" before the HOT numbers.

3 more plays for this week, maybe alternating between the 2 picks is in order.

Have a feeling that the jackpot will be hit, by at least 1 winner, BEFORE it crosses the $5,000,000 mark. Then I can go back to that last week of pick 5.

After the fed and pa taxes are taken, a solo winning ticket would be worth $2,786,745 (or more, I always take the worst case scenario... 37% federal and 3.07% flat PA tax)

Shortcut calculation for winning in PA is <prize> x 0.5997

That is the quick estimate of what a prize is really worth.

Still waiting for several decades to use that formula for real...

Going to start on the path of getting the answers that spreadsheets and python are not answering.

Installing PostgreSQL 18.3 and building a knowledge base of queries.

Should be an interesting learning journey!

Why? Rolling jackpot up to $4,380,000!

When it gets hit i will pick up that missing p5 week.

Since results are just not there in the pick 5, I am skipping the pick 5 for the next 2 days... going to try a one off experiment with the Python random number generator...

Since it is documented that the PA night games use 9 ore draws, 3 rehearsal draws, a live draw and 3 post draws every night, I reworked the QP generator to output 16 draws and will play the 13th pick for both the Cash 5 and Match 6 for tonight.

Skipping 2 pick 5 draws keeps to the budget for the $4 expense.

I expect nothing, but it will be interesting to emulate the process...

Since the previous 2 systems are focused on a per column approach (because the positional digits are independent), I will stick with a per column approach here as well. That means eliminating the horizontal sum portion, which will simplify the spreadsheet.

The end result will be a cascading sheet, where the groups of columns get shorter as the calculations move across.

The first columns will hold the draw history, the next columns will start ten rows down and sum the 10 rows that make up the first k sample. The next set will make up the N sample size, so they will start 30 rows below the k samples and provide both an average and a mode.

There should be a way to run a basic back test right in the sheet once the data is populated for the average and mode of 30 k samples. That would be to take the average and mode (separately) and subtract the last 9 in the k sample and see if it is equal to the next digit. In this way, if the initial k and N parameters are inconclusive, they can be changed.

It is a great deal of tedium creating such a sheet, but that will serve as the base of coding a function in Python, as the commands to get such data in a pandas data frame are much faster.

So we will see if there is any merit to such a system by counting hits on the back test. That will decide whether it is going to include a mode or an average (or both) when it moves to Python.

This is still a single approach on 3 independent histories, so there will remain that synchronization issue. Hopefully the specific profile information for each gathered from the other 2 functions might be used together at some point to determine the "state" of each position.

I could make the single script prototype open to settings where k and N are different for each position...

At some point I may need to record the output of all of these functions and feed it into a machine learning algo or 2 to find stuff I am currently not seeing.

The sheet is built, with one tab for mid day pick 5 and one sheet for evening pick 5... so far the sums(k) are done as is both the rounded average and mode for the sample size (N)

From here I need to calculate some summary statistics (the range of the sums, the range of the samples and their distribution), and then come up with a formula to test the effectiveness. This part may take some time...

At a quick glance, there is an expected difference in the positions, some run higher (consistently) than others.

Would have been easier with the pick 2, but in this test I wanted more columns to compare.

Not about playing it, have no plans on that at the moment, but on including it into the app. I have not yet found the ID that corresponds to a data page like I have for the other games. If they did not create one, then there is no pathway for creating one using that method. So I will explore the options...

1. Writing a quick script to run through a group of IDs, using the scraper to extract the H3 page element containing the game name, and excluding the H3 message for an ID with no data.

2. Look at another participating state that either has an api or a similar page of year at a time data.

3. Explore the MUSL site for the same.

Or

4. Drop support for the game in the app.

The current setup has data separated for bonus ball games, but it does not need to be separated if it is the only workaround. It will just not have correct settings for the bonus ball itself and the stats will be off.

Either way, I am removing the Cash 4 Life data and metadata.

Have an idea for visualizing the classifications from the back test data... running an animation of the classifier changes in each column side by side using the matplotlib and Seaborn libraries. This will be a stand alone side script not intended to make it into the app.

Also taking the next steps with vertical sums, which is still in the spreadsheet stage. The changes will include summing 10 draws instead of 3 (pick 3 example) and taking both the AVERAGE() and MODE() of 30 samples instead of the whole column. This incorporates the size calculation I did where k=number of balls in the game x N samples, which is 30. I am designing this vertical sum to be a drop in function for the app.

At this point, the plan is to have 3 separate functions to analyze the data, and find a way to infer from the 3 results to make a best guess. This week, the expense is only $8 as the days of play were reduced from 7 to 4, but the mostly winless annual tally is -$104.

I did plan on playing all year. The goal of completing the app was met almost 10 months early, so now I can use the time on refinement and learning how to better interpret the data.

The new routine is to first check where the winning numbers sat on both functions before updating the draw history, so I will wrap that up before the python/spreadsheet work for today gets into full swing.

So far it has been determined that the endpoint I use has not been updated for new games since the introduction of the Cash 4 Life 10 years ago... yet the data is updated daily... so they must point to a table or database that is the single source of truth for all game data. Time to investigate the front end "view past winning numbers" page to determine where the new data for Millionaire for Life is stored.

The stats screen for the follower function provides different data... note the total followers... adding up the frequency of each follower will match this number. The last 10 are the last 10 followers, there is no indication of how many draws elapsed in this range. And the last number drawn is a quick check to make sure the updater is working. The draw in this example is NOT the latest, and that is an added benefit of making the updater user initiated as you can see what you had to work with the previous draw, see where the winners came from... then update to get current data.

This image from the app confirms that not only are the draws independent events, but the individual positions are also independent of each other. Wide swings in variance and the distribution of classifiers. One thing noticed is that the few draws I have seen since adding the above and below median categories are the winning numbers almost always come from a transition area.