Development - G.A.T. Engine 2.3

[lottoarchitect]

Prerelease 1 also do that. Actually even GAT 2.2 do that cleanup, this cleanup exists since the introduction of unlimited GATs. The necessity to check more things during that cleanup made that delay more apparent like the new buildup mode. There is a way to avoid some of that delay and I'll try to improve it for the official release among other optimizations. Just observe if the delay occurs at every 10000 GATs, if not, something else is happening although the only delay I observe here is due to that cleanup. Check it and tell me at which GAT IDs it does occur.

it should list gats in a simple ascending order, like in prerelease 1.

What's the point to go backwards? First the X, X-1 feature rely on the ability to display GATs not in ID order but in productivity overall, therefore you'll have GATs anyway showing up in no ID order. Secondly, among those that deliver the same X hits, the one that is better overall in all other hit categories makes it to the top so this approach magnifies the fact that a GAT showing higher is better overall than any GAT in lower row. Older versions couldn't make that classification therefore it used the simplest approach to display the first found, first shown. This doesn't mean this initial approach serves something beneficial - which now has been lost - like the current approach do. I don't think using the first found first shown method has to offer anything better compared to the new approach so I dropped this altogether and I see no reason to bring it back (it doesn't fit anyway due to X, X-1 approach).
To put it in a different perspective, assume two GATs, lets say GAT #1 and GAT #1000000 that both deliver the maximum hits at a given category.
GAT #1 let's say it can produce 50 hits at X category, so does GAT #1000000. Also lets say we have found another 1000 GATs that also deliver that 50 hits, all these before reaching GAT #1000000. So this latter GAT, will not make it somewhere in the panorama with the initial first found first shown approach.
Additionally GAT#1 besides those 50 hits produces a spread of hits in lower hitting categories down to 0, lets say 20 0-hits, and 20 1-hits. GAT #1000000 produces 0 0-hits and 40-1 hits. With the old aproach you'll see only GAT #1 which obviously does a worse job as a predictive GAT because it has failed in at least 20 draws to pick a winning number. However you'll not have the chance to find out that there is an equal GAT in terms of X category hits that does quite better in lower win divisions. Ultimately this would mean this GAT #1000000 has a better focus overall compared to GAT#1. So, in any way I approach this, I see GAT #1000000 to be better than GAT #1. The old method would propose only GAT#1. The new approach will give you GAT #1000000 and GAT#1 would be surely withdrawn to favor other intermediate GATs that still deliver better overall. I hope you get the point why the original approach was dropped to favor something better. First found first shown is not a better approach, it is just a method used due to lack of more precise selection which is now added.

lottoarchitect

[baalhabait]

Yeah, i got the point in the first place, and for sure it is a better approach...
When the cleanup occures, i see "not responding" for a few seconds,
Is this supposed to be like that? What about making the bulid up mode to be initially selectable?

[lottoarchitect]

You shouldn't really notice a cleanup delay, I'll try to fix that with an optimization. Prereleases serve the purpose to first find new additions and features and during that stage to identify bottlenecks and fix them too. This is one such case here. The official release shouldn't have that issue.
The ideal would be not to have any user selectable option for the various modes. The only reason this is added is to speedup things when some modes are not used by the user. In practice that means the user will have a list of modes to select via checkboxes, the drop down list cannot work with more than 2 options (augmentative/absolute/buildup and something more if it is added). All these will be added at the final prerelease to be evaluated altogether.

lottoarchitect

[baalhabait]

How far the new additions will impact calculation speed?

[lottoarchitect]

No further additions will be made to that part, only optimizations are left to be done so only speed improvements can be expected for the official release. Due to the nature of the X, X-1 feature however, we can't reach the initial speed of first found first shown method. The older approach didn't have to make any sort of real comparisons against existing GATs in a column and place it accordingly, it just appended the table in the column. I'm sure however the benefits of these new features worth that reduced speed.

[lottoarchitect]

Some further news to the development.

- Added maximum GATs to scan.
- Fixed the delay due to cleanup. Actually the optimization now allows the engine to perform slightly quicker. This speedup becomes more obvious the more GATs per column shown or letting more columns overall.
- Panorama modes now are individually selectable via checkboxes, so if the user doesn't need the buildup mode he can disable it to speedup the system. Also the options GUI has changed to group relevant things together.
- Export history draws function. To access that feature, right-click on the lottery draws display.
- Auto-load last active lottery.
- Protection against a false license lock that can occur if we attempt to run a new GAT instance before the first instance fully opens (i.e. because of a delay with the server response).
- The automatically saved options for each lotto game have changed to .ini files. This was made to make easier future upgrades. The new version will not import the saved options made by the previous prerelease so keep a note of them to re-enter the settings to the new prerelease.
- Added pause/resume during calculations. When paused we can still use all the available functions (i.e. browse GATs) and also export the current engine state so we can reload it at a later time (this export function is still under development). Also if we terminate the calculations, we have the option to resume again even if we got back to the main GAT's window (given no options have changed).

I currently work on the save current progress functionality. When this is done I'll make a prerelease available. I have also made some tests regarding a proposal to color GATs in the panorama that reside in various columns. It turns out this offer no real benefit since many more GATs do reside in various columns that don't hit so in practice this doesn't seem to offer anything useful. Further requests should be posted here.

cheers
lottoarchitect

[baalhabait]

Hi anastasios,

Do you remember to add the browse retained gats?
Perhaps there is a way to internally understand why gats produce their each particular results and then attempt to find other gats that suggests similar behaviour before they hit brilliantly?

[lottoarchitect]

Yes it is further down in the TODO list.

Perhaps there is a way to internally understand why gats produce their each particular results and then attempt to find other gats that suggests similar behaviour before they hit brilliantly?

Any ideas are welcome.

[baalhabait]

Since gat is your idea, you are the one and only who knows how it going on internally and i can not give any idea regarding what is completely unknown to me.
Same as results are based on initial signature, i assume each gat has its own self signature which might be found on other gats as well, and any hit is actually the result of some particular initial signature.
I cant give any idea regarding how to find this signature, but nevertheless you were the first who thought about this when designing GAT...and though no one was there to give you the brilliant idea, GAT is existed.

[lottoarchitect]

Well, GAT is a beast really. As I have said several times so far, the only evidence of what a GAT table can provide is its overall performance over the test period. Each GAT is derived from the previous GATs and influenced by their signatures in ways I can't even describe. What we look for in a GAT table hits graph is sort of a repetitive performance, which ultimately means the signature can get back in track every so often and whilst its on track, it can provide some good consecutive hits. If for some reason a consistent performance seems to end after a very good hit sequence, this is solely attributed to the dynamics of the game that have changed too much. Such an effect can be easily observed when we test against very few test draws. The computed dynamics in GAT is essentially the signature in any way it has been formed to that point. The "relationships" can grow to an unimaginable complexity but the fact remains the same, each GAT table has formed its own idea of what are the dynamics of the game and this is applied to the current GAT table to make the prediction, therefore it is really impossible to recombine somehow signatures of various GATs or even find a way to extract the elements in a signature that do give the good hits. So I really cannot see what else I can do to the core logic. Ideas like the synthetic come as an aftermath of what the signatures deliver on their own.