hypersoniq's Blog

After months fine tuning the windows version of the app, I put the project files into docker through the windows system for Linux (Ubuntu) and made the edits to the buildozer.spec file. It is now generating the first APK version of the app... The process is taking hours (4 so far) but it is doing a great deal of work behind the scenes.

In addition to python, it also requires kivy, kivymd, pandas, numpy, requests and beautifulsoup4. They take time to compile in c for use on the ARM architecture of an android phone. This long initial phase was expected, and future updates will take far less time. I will get to test this when removing Cash4Life later this month.

I expect no easy ride at any phase of this, but the potential is I could have a functioning app on the phone tonight!

Added an "about" screen that will work on Android. That was relatively simple at this point. The tricky part is that unlike Django or Flask, you can't just use CSS to make everything flow correctly. Kivy has it's own layout rules. There is a version number that displays on the About screen.

The last refinement will be cleaning up the information displayed on the column stats cards so that it flows well at mobile aspect ratios. After that the hard work is essentially done! (For the Windows version... then the real work begins for Android deployment... Docker, Buildozer, that all important first APK...)

Once I have the card displays down, I can take a few screen shots... the mobile version may be ready for use within a week! Just in time for the first Pick 5 cycle.

The first planned update will be replacing Cash4Life with Millionaire4Life, I am sure that will come with it's own set of challenges and "learning opportunities".

The (now) months of work are coming together in a slick professional application that serves as a system framework where any new ideas can be dropped in with relative simplicity compared to the old method of writing a different script for each idea. Even if it never picks a winner, it was worth the journey to see what software engineering is really like.

So, as the first 7 days of the initial pick 3 attempt hits their last day (and eve) and it went winless (also as expected), the observations...

1. All numbers appeared at least once in their predicted positions. Today's mid day had position 2 AND 3 correct. This is the first look at lag testing.

2. This was off of all raw data from the app, pick the most frequent follower from each column. Running the app again tonight for next week's picks gives 2 different combos for week 2.

3. The ideal window remains next draw, but I do not have the opportunity to play both games every single day. So the week long play frame is the better choice for now.

It was interesting to see each number appear in position over just 7 draws, and I will be watching that over all 3 weeks of this first pick 3 run. Because the entire system is per column, I hope to see something similar in the pick 5.

All of the questions I have about the data should for the most part be answered by the big sliding back test... but that will have to wait until I finish the Android version of the app, as the data presented will remain unchanged, the back test will provide information (hopefully) on how to better interpret the data.

The process of getting picks, from launching and updating the draw histories to reading the data for both games was done in under 5 minutes... on that front, the app is already a major win! Once this is on the phone... max efficiency!

On track with the plan, it's fun to see an idea take form. Getting things right and meeting the challenge of getting ahead and back to stable with each coding session was rewarding in it's own right. Hopefully a few wins will follow... the manual updates and expanding to 14 different games leave many options for future play ideas.

Getting there one git commit at a time...

So far the app has game banners for the game select screen, a logo at 3 sizes and an icon at 3 resolutions... set up for Android!

The work flow was set by the type of file, start with svg files created in Inkscape, then batch convert them to multiple sizes to png files for use in the app, as Kivy or KivyMD do not have a native way to work directly with svg files.

One of the issues I ran into, unintended transparency, taught me something really interesting about svg files... they are human readable when opened with notepad++ !

I was able to find the lines in the svg code (which looks a great deal like XML) and set the transparency directly! I was then also able to set a solid white background rectangle on the game images, because some of them had one, some did not.

So, the game select screen is 100% done. The splash screen is done and looks good, and now it is just going to be figuring out where the logo would best be placed for branding on the other screens. Once this and the documentation are done, I think it's Android conversion time!

Next chance I have to work on it will be Friday, so I may try to get a screen shot or 2 up here.

So what is it that would be useful to count?

The obvious is "did the numbers at the top of the transition distribution list ALL match the next draw?", secondary would be if ANY of the numbers matched.

This means there are 2 scopes to check... the per column scope, and the combined column scope (whole draw). Which scope the script is in determines the output timing. Setting per column variables to capture the data that can then be resolved at the top level across all columns seems to be the implied flow.

So at the column level...

1. Did the number at position [0] (most frequent) match the value of next draw for that column? A 1 for yes and a 0 for no. Accumulate on a variable which will then have a value of 0 to 3 on all columns ran. (Pick 3)

2. Which index position (if not [0]) DID match the next draw? 0 being most frequent, 10 being least frequent.

3. Was the next draw value contained within the "last 10 recent followers" list? Boolean... True or False. This will allow testing of the usefulness of that feature.

Then at the whole game level...

1. Did the accumulated variable equal the number of columns in the game (3 for pick 3), which would be a valid [0] [0] [0] hit?

2. Did the combo indicated by the distribution list appear in the next 7 draws? 14 draws? 21 draws? This will test for lag.

This set up will answer a few questions.

A. Over the entire game history, would playing the most frequent indicated transition in all columns have turned a profit? I am always expecting this to fail, but this time I am interested in how much it fails by.

B. If not [0] on each distribution list, what were the most frequent patterns of index positions that matched the next draw? Re run the back test counting the most frequently matching index values.

C. If there is a lag component, how long is the duration?

So not worried about accumulated errors, this is more about the frequency and report index position than the actual numbers. On general frequency data, the distribution approaches the expectancy of 10% per digit. In the case of this Markov Chain, we are focusing on a specific event... numbers that followed the most recent draw.

That would make the first 3 entries in the row a 1 or a 0 for a match of [0] to the next draw (for pick 3). The next 3 rows will display the actual distribution list indices of the next draw. Followed by the cumulative value of the first 3 entries in the row (3 = straight hit on pick 3) and finally an indicator to show where in the next 21 draws a lagged straight hit may have happened. If it was not in that window, value = 0, if there was a hit, then it displays how many draws past the next drawing the straight came out.

I think that is the most comprehensive back test I can think of at the moment. Writing to a csv file for import to Excel will help get an accurate picture of how to read the transition report moving forward.

Keeping in mind I must write this on a universal scale to process any game, from the pick 2 to the match 6/power ball/mega. This will be awhile to put together, but it is always better to start with a plan, an idea of what output you want.

But this is best kept at the script level, as the app just presents the most recent data.

Don't know when I will get to it, designing the logo for the app today, then putting it on the splash screen and a smaller version on the top bar. Also designing the icon image.

Since I am brand new to development with KivyMD, I use the free version of Microsoft Copilot in the role of a tutor.

This works because I did learn how to make basic applications for Android and iOS in school, so the help came in the form of prompts like "In Android development I could do <insert task>, how is this accomplished in KivyMD?" It would show me the basic design pattern and I would then work on implementing it in the code. It is also helpful in solving complex trace errors in Python, as this is now a complex app structure.

Kivy (and kivyMD) allow me to leverage the python skills I have built up in a real structured application without the overkill of a big Python framework such as Django.

So I would follow the design pattern of designing from the start screen down every button path, building screens and solving issues as I go. All of the issues with using AI quickly disappear if you use it in this manner. Since it is not writing the code, it does not hallucinate. I tend to pick descriptive variable names and file names so I can tell what is going on easier. Since I am not relying on AI to do the heavy lifting, there is no complex or poorly designed "spaghetti code" to unravel. No paid AI account required. Could have used ChatGPT, but one thing I have found is that giving Copilot a "role" like a tutor, it does a better job of only giving you what is asked AND explaining issues like Kivy UI timing that I might not have fully understood just starting out.

The bottom line is that AI can be useful without becoming a crutch, IF you already have coding experience... I have no idea of how "vibe coders", those who generate code without knowing anything about coding, do what they do.

Sure it is taking me months instead of days or even hours to get this done, but I understand how everything works because I built it. When it comes time to replace Cash4Life with Millionaire4Life, I know exactly what files need to change and where to find them.

AI does help keep focus to the task at hand as well, instead of trying to solve all problems at once, I am learning to resolve issues and implement features in a clean and organized manner.

Took 10 svg game logo images from the PA lottery website, batch converted them into png files and imported them into the project. Added a file path to each within the game's meta data structure (re using the pick N game logos as they do not differentiate between mid and eve) so 10 images for 14 games.

Also fixed an issue where the column headers were not exactly aligned with the data, it is spot on now.

Got a bit of a work stretch for a few days, but when I get back to it, the fun part of creating a logo and applying it to the splash screen can begin. Function first was the right engineering approach, as all of the heavy lifting is pretty much done. Every layout decision made was with Android in mind, so the first iteration of that version should go relatively smooth compared to this learning experience.

The only permission required will be INTERNET, so the csv files can update.

There will be some drudgery coming up when I go through each and every file to ensure it has proper comments, remove any errant console debug prints and include proper docstrings on EVERY Python file to help generate some technical documentation, as well as composing a "user manual"... perhaps even a context sensitive help system to explain screen elements at each section.

It is really starting to look like a slick, professional application! 

I spent a good hour or more trying to crash it by generating various game combos, but the issues found early on appear to be fully resolved... go from pick 2 to power ball, no index issues... no word wrap, no truncation, ability to scroll to see ALL of the data... universal versions of my older scripts that return data structures rather than just print to the console... all good stuff!

Cleaning up the info display on certain column stats pages is probably the last tweak needed to get a clean display on all 14 games. I feel that this is not far from that first attempt at compiling for android... WAY ahead of any imagined schedule, which was initially ALL of 2026.

Now if only it produced data that identifies winners... first crack at pick 3 missed 2 of 3 numbers on each game today... Hey, if it was easy, everyone would be doing it...

This one was a bit of a milestone as the windows app was used to make the guess.

This is also a departure from the most recent strategy. Here I am looking at the Markov Chain of followers, but instead of playing the highest frequency combo for 1 day, I am playing it for 1 week. This allows focusing on the chain transition frequencies. So this week is the basic approach, which number has the highest frequency in each column?

Next week, instead of playing the same combo, the report will be run again for the numbers drawn next Wednesday.

One feature of the report for column stats is the last 10 followers, this will be figured in at some point, but for this first week of the pick 3 cycle, it will be the raw output of the follower function which is also being tested for 7 draw lag.

So adding $14 to the $40 overall loss on the Match 6 cycle brings the tab to $54 so far. Next Match 6 cycle will be similar to the process for pick 3, new combo every week.

Considering the $16 won from the Match 6, the total year cost is now $712 instead of the original zero win figure of $728.

If I happen to catch a pick 3 win, the first move is to recover what was spent to date, then from what is left, use that to cover as many cycles as possible. So if I were to catch a pick 3 straight in the next 7 draws (mid or eve), I take back the $54 spent, then with the remaining $446 let the state pay for the next 31 weeks. It would only take 2 pick 3 hits to have the state fund the entire year... but there are only 15 total pick 3 weeks in the full cycle plan for the year. That brings up the possibility of completely cutting out the Match 6 (if the next cycle does no better) and just alternating between the pick 3 and pick 5. Not there yet though, I did want a jackpot game in the cycle, and the Match 6 meets the hard budget cap of $14 for a week.

On the dev front, I installed the free svg drawing program Inkscape (a free open source program) and got it working with my drawing tablet, so the graphics portion of app development is under way. Also fixed a timing issue where the app would hit an index out of range error when first looking at a game with less columns and then opening a game with more columns... it was a race condition similar to what you might find when coding in C, the UI tries to display the rows without first recalculating the column width... worst part was that the python code is correct, it was a kivy timing issue that had to be solved from the error messages. I fixed it in the kv file by having the code wait until all of the data is returned from the build_row() function BEFORE trying to display it. Timing corrected, crash condition eliminated! It is all about testing edge cases, and I am trying my best to find ways to break the app when using it so issues can be 100% resolved before the big move to Android.

Another thing I am preparing for is that I want the status bar (time/connectivity/battery level) to stay visible on every screen in Android... that has to wait until the Android stage to incorporate... but I am planning for it.

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