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.