hypersoniq's Blog

Finally fixed the stale path issue! Now the updater works correctly in the app_user_data space, where it has permission to append the csv files with new data!

Next and hopefully final issue was a mismatch between a successful run of the main functions vs returning an error... type not compatible. A good run returns data in a tuple, if the except block runs, it was returning a standard error message. Simple fix to handle the mismatch, just package the error message as a tuple! Now on this rebuild I can catch the actual error in the ADB logcat and solve it... then the apps on both windows AND android will be 100%

With the error not returning properly, it is never displayed in the error logs. So one more problem to identify and solve.

What a journey!

Even a fancy new wrapper for the logic has yet to make a match. Since I am tracking, the amount spent, counting today's week 3 plays comes to $82. (Even a frugal budget of $14 a week adds up!) It would have been $98 save for the $16 won on the Match 6 cycle.

Always have to assume that there will be zero hits. That means any actual win does reduce the year cost. With $16, I am down from an initially projected cost of $728 to $712.

Tracking the rolling out of pocket expense will make it easier to split a pick 3 win into payback + weeks on the state. But if dumb luck is still the most important component, I hope I get a coincidental win on the Pick 5 cycle! Then I can pick up a Macbook pro and get my app running on iOs devices like my iPad as well.

With this app, ALL of the engineering happened on the windows side. The Android part was basically assembling the app from the blueprint I had made in windows.

The plan...

I know that I must copy the csv from the data folder to the folder in the app that holds user data. I need to see what that path is so I can get it there. So, I am recompiling with some diagnostic prints that will spell out the path clearly in the ADB (Android Debug Bridge) logcat output, filtering the exact output of that print statement rather than going through thousands of lines of output. The print statement will reveal the exact path to the user data folder... then I will have my destination to put into the config file that will make the data "live" and will allow appending draws with the updater. Right now the "data" folder in the project files is read-only. This should be the last step in having the app 100% functional on 2 platforms!

And the ultimate test for data validation will be to match exact output of the windows and android versions for a few table and stats screens... 100% match = mission accomplished.

Anything else done to the app will be ui tweaks to make it look better... until they sunset Cash4Life...

At that point I will need to insert Millionaire 4 Life and remove Cash 4 Life, but here is the challenge... for that game, classifier sample data, following the formula, will require 870 draws (58 balls x the chance for each number to appear 15 times), so I am building logic that will keep the classifier button grayed out until the csv file has 870 draws in it (871, counting the header)

The Markov/Follower will run clean even with 0 draws, it just outputs nothing, but the classifier is not designed to run data starved.

After this, the work shifts back to the script lab for the major follower back test script that should provide some clues on how to best interpret the output. Also to determine if full history vs a sample yields better results... if the sample does a better job of holding onto the volatility, that can be changed in the app following the same formula... engineer on windows, assemble on Android.

Though this part is absolutely frustrating... 10 builds in and still the stale data problem... checking the data consuming funtions....

This is for the pick 2 mid day, the output is simply (number, frequency). The frequency is how many times did these numbers follow the number last drawn. You read from top to bottom and can equate higher frequencies with higher transition probabilities. Keep in mind this is still stale data from the apl as I am working out where to copy the csv files for write access, but the fact that the app launches with zero crashes on my phone still = mind blown... this is pure Python running on Android!

Also, this obviously does not actually tell you the winner, as the Markov chain only needs the last state to calculate transition probabilities, but each draw is independent of the last... but it looks good! Had to try.

Here is the classifier output of the pick 2 evening game. This is the classification (H is hot, N is neutral, C is cold) of the last 150 draws. Data is read as [number, frequency, classification, percentage to the sample, draws out]

After having windows update force a restart while I was sleeping, have to rebuild the whole thing from square one. Deflating for sure, but that 6 hour process (9 year old laptop runs slow for this type of heavy lifting) has been started again. Nkw I expect to have data available when re installing. Here is the screencap from the splash screen, logo and the acronym spelled out...

here is a screen shot of the game select screen in my app. It scrolls down for the jackpot games. Had an issue with the csv files not being packaged in the app, so another 3 hour tour in buildozer, but the app does launch on the phone!

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.