Tutorial - Typical usage examples of GAT Engine

G.A.T. Engine general discussion
Post Reply
User avatar
lottoarchitect
Site Admin
Posts: 1635
Joined: Tue Jan 15, 2008 5:03 pm
Location: Greece
Contact:

Tutorial - Typical usage examples of GAT Engine

Post by lottoarchitect » Sat Feb 15, 2020 12:52 pm

This question comes up regularly, so it could be a good idea to post some general usage ideas of this program.

First, we need to clarify that the engine will never stop scanning; the process is open ended and means it will always scan to find even better overall solutions. So, no popup message will show to say "JOB DONE". Typical runs may require up to 1 or 2 million scanned GATs, less or more but the advice is usually to let the engine run for as long as we are willing to wait for predictions. In reality 6-24 hours will yield close to the best that may be found.

1) The default and original operation is the use of Run Factor. This mode is applicable in all panorama modes. The idea is to pick a GAT which demonstrates good desired qualities. The reality is all the proposed GATs that end up at a panorama mode are already competitive GATs to pick. It doesn't matter that much which one we may pick as long as we are expecting to keep using that GAT in the next few future draws; its proposed quality is expected to show up sooner or later. So we can equally pick randomly among all the proposed GATs. If we want to invest some more time in examining these GATs, the advice here is to pick GATs in the middle columns mostly (i.e. 3 or 4 hits category) as these have the property to produce more regularly at least some medium hits compared to the others as demonstrated by their hit performance. We also care for the regularity of hits observed in the red graph. That means we want our picked GAT to produce a desired hit all over its test range, not having all the good hits concentrated in only part of it. Once we decide on which GAT ID to use, we retain it at several future draws. The idea here is, this GAT may not be successful at the very next draw but its overall qualities are expected to show up within the next few draws (the 100/X rule). Remember we retain the ID, that means we perform a new scan with the new draws of the lottery to get the new numbers that GAT ID proposes (and Run Factor increases accordingly).

Make a search in the forum about regularity of hits, 100/X rule and Run Factor utilization for more detailed info on these terms.

2) Using several GATs as individual predictions. In this approach we set the engine to request the minimum of numbers our lottery can draw. So if our game is e.g. a 5/50 one, we'll examine only GATs requesting 5 numbers. The idea here is, most GATs will not deliver the good prediction at the next draw, some may do, but their overall characteristics are expected to emerge within the next few draws (the 100/X) rule. Typical advice here is to either use augmentative and GATs at the middle columns (see method 1) or the Hits+delay panorama to make our initial pick of GATs to use. Set the "GATs per column" setting to the total blocks we want to play i.e. if we want to play 20 lottery entries, set "GATs per column" = 20 and pick all the GATs in that column. Nobody forces us to a column however, if the user feels the need to pick GATs in other columns too, by all means use them.

3) A combination of method 2 above and method 1 with Run Factor. Once we have established a set of GAT ID tables to use as per method 2 above, we retain them and follow them in the future draws with the use of Run Factor.

4) Once-off approach with the build-up panorama mode. This aims to trap the GATs that seemingly have focused on the signature of the lottery, so we expect this to continue at the next lottery draw. This is typically an once-off approach, not suited to use with Run Factor. The only exception is if that particular GAT we picked does deliver the desired hit at the exact next draw in which case we may want to continue with that GAT expecting to perform again. We can also use method 2 with build-up mode by requesting the bare minimum of numbers and picking as many GATs as needed to pick our individual tickets.

5) There are even more advanced ways to use GAT ID tables. i.e. try to find the numbers most occurring among the various GATs as the best candidates to use. Variations could include various runs with different settings for tested draws/stat.data settings. This goes beyond this simple guide however. Users have also posted their methodologies, like the ablation approach where we try to suggest what numbers to eliminate from our current selection.

Finally, the absolute mode is more tailored in matrix constructions. If a good GAT is to be successful in this mode, it will be already proposed in the augmentative panorama, therefore no need to check the absolute panorama mode if we do not plan to make use of matrix constructions.

user2187
Getting used to it
Getting used to it
Posts: 7
Joined: Wed Dec 01, 2021 10:26 pm

Re: Tutorial - Typical usage examples of GAT Engine

Post by user2187 » Wed Dec 01, 2021 10:31 pm

Hi, I have some questions here:
In method 1:
1- Can we conclude the quality of a GAT by comparing it with the actual draw result and then mark its ID? Or it’s better to use the hits/delay in the software only?
2- If we pick GATs in the middle columns mostly (i.e. 3 or 4 hits category), as I understand we need to assure that the ratio is 100% to make the GATs more reliable, but in that case the numbers requested will be high (for example in 5/50 lotto if we have only 100 draws, the numbers requested which assure a ratio of 100% for the 3 hits category is around 25 numbers in each GAT, so how to get use of these GATs (i.e. we have each GAT giving us 25 numbers with 3 expected matches, if we wheel them we will get high number of tickets) any suggestions?
3- Let’s say we marked some GATs as retained GAT IDs, and we added a new ticket to history and we made a new scan to generate new numbers for those GAT IDs, how can we export of all of those IDs at once? And how we can get use of them? By wheeling them?

Method 2:
The GATs that requesting 5 numbers usually have 1 match only, and usually they are in category 1 to assure a ratio of 100%, if we use the middle columns the ratio is very low for requesting 5 numbers, so this method is not much clear. Also, if we play 20 lottery entries with those numbers, each entry must match at least 3-4 numbers to get a reasonable prize while the actual match is 1 match only.
I think it will be better if you can make a short video tutorial because the text sometimes cannot give the clear picture and steps.

Method 4:
As understood, you prefer the “Augmentative method with run factor”, but since the “Build up method” uses the same history numbers to expect the next game, what’s the problem with it? And what if we used the run factor but we used the “build up” results instead of “augmentative” will it be accurate?

User avatar
lottoarchitect
Site Admin
Posts: 1635
Joined: Tue Jan 15, 2008 5:03 pm
Location: Greece
Contact:

Re: Tutorial - Typical usage examples of GAT Engine

Post by lottoarchitect » Thu Dec 02, 2021 12:29 pm

Hi user2187, to your questions

Method 1 - 1) outcome on a single draw practically means nothing for the performance of a GAT. The outcome proposed by the engine rely on an average performance achievement for all the modes that work that way. The only exception to that is the logic behind "build-up" in which case, if it fails to deliver on the draw it was used, no expectation for a further hit following that failure can be estimated. If you observe the hits performance of GATs, you'll see they have ups and downs in making hits (red graph), some areas will have more hits some areas will not produce noteworthy hits. This is what we refer to as hot/cold cycles. During each cycle however you'll always have non-hitting outcome (i.e. most draws will still NOT produce hits in a hot area where some good hits are produced). This is the reason the overall averaged hits production over the span of the tested draws is used to estimate the performance of a GAT, because we cannot really pin-point exactly the draws that will deliver that result but we can estimate "how often" we may expect that better hit (the 100/X rule). For that reason, comparing the outcome of a GAT against that one draw does not make sense really for the way the engine works. Doing so nullify the Run Factor usage to begin with and the logic behind using it.
The hits/delay logic is used internally by all modes to further classify GATs in the columns meaning if one GAT has equal average performance to another one, if it "scores" higher in the hits/delay analysis it goes above the other GAT in the column. It is another way of looking at the data and offers another level of classification. Still this also experience the "average" logic considering the total hits used for the evaluation come from all over the test range and the delay information again comes from analyzing when these hits occur during that test range. If you read the manual, still it suggests this mode is useful with Run Factor as well i.e. not an once off attempt. In short, whatever happens with one draw doesn't mean much for the performance of any GAT.

Method 1 - 2) We don't have to assure 100%. The only reason we suggest to prefer these middle columns is because during the waiting time to get the better hit, we also expect to have less good hits emerging and usually these also result in some money earned whilst waiting. You can equally disregard this advice and use whatever column to pick the GAT to use. We don't require 100% hit performance for e.g. a 3-hit but given typically a 3 hit result gets a price, this is why we prefer the GATs that demonstrated the best performance in achieving that. Consider this, column 1 will typically be close to 100% but getting one correct number 100% usually does not result in getting a prize and more often than not we don't observe a quite better hit delivered, this is why we do not suggest using column 1. This is why we go for the middle columns.

3) These isn't a way to export all the predictions of the retained GATs in one step. I'll add this function to the next update. To get the predictions of the retained GATs, go to the "GAT Table" display, enable browsing of the retained GATs (right-click on the ID number at the left of the slider) and go through each GAT using the slider and copy the prediction numbers. The idea of following GATs in the future does not involve following dozens of them. In practice you may follow 2-3 because they looked like they are very good GATs to disregard or we may want to perform more advanced analysis using their picked numbers like the ablation method or whatever idea we may want to apply. In principle, if we pick more than the bare minimum of numbers, a wheel is to be used as a means to cut down the cost so just one GAT is enough if we request more numbers. I cannot offer advice on when/why you may want to follow/retain many GATs; it is up to the user and the approach he wants to use like perhaps the idea of method 2. Retained GATs is a feature offered to allow easy use of Run Factor use and to forbid the engine from discarding those particular GATs.

Method 2) This is quite clear actually. As explained above, a GAT is not judged by the outcome of one draw. It doesn't matter if we want to pick the bare minimum of numbers or follow a GAT that delivers e.g.15 numbers, the idea is the same, the demonstrated performance is expected on average around every 100/X draws. So, we want at least to observe a GAT for that amount of draws plus a bit more. Method 2 proposes the idea of monitoring GATs requesting the bare minimum of numbers. From one point of view, if we pick 5 GATs we have 5 individual bare minimum number predictions to play. If our budget is 10 euros and each ticket is 1 euro, we can pick 10 GATs to use here. If we want to spend 20 euro, we can pick 20 GATs to pick 20 individual predictions. What is important here is again the principle of 100/X rule. All these GATs will probably don't produce a good hit at the next draw, one may do but even none will, we still expect the good/better outcome to emerge during the 100/X span of draws; one after the other among those GATs will provide something better. All the selected GATs in this method should be placed at the retained GATs list and keep using their prediction in the future draws. So, let's say you have a budget of 10 euros (ticket cost 1 euro), that means you can afford to play 10 tickets each draw. The first time you run the engine to decide on which GATs to pick for use. Again the idea of using the middle columns is the same as described above. We play all the tickets proposed by these GATs. Since we request the bare minimum of numbers, each set of numbers proposed by a GAT is a ticket to play. We retain all these GATs for use in the future draws too. The next time after the new draw comes, we run the engine and pick again the predictions of those retained GATs. We continue that for as long as we want but the general advice is to go as far as the span computed by the 100/X rule. This span typically should be in the vicinity of a few draws ahead. This typically couldn't be achieved with the bare minimum of numbers so set a hard limit to stop playing with that method if no good hits emerge at all, like 10 draws ahead.

Method 4) There isn't a preferred method as this suggests there is a better approach and the others are worse. If this is the case, there is no reason to have any other approach to use. Augmentative + Run Factor is the default usage method and is considered "more reliable" in the long run because it rely on average performance which also includes the hot/cold cycles experienced. All the other proposed approaches including build-up/hits + delay try to "catch" the good hit sooner but this also is not so consistent compared to the default operation. Build-up specifically is considered one-off only for the next draw because the assumption and the reason a particular GAT is suggested for use cease to exist if that GAT fails to deliver at the next draw (the smooth build-up of hits production). Since gathering these GATs does not rely on the "average" performance principle, we cannot really suggest these will do well using Run Factor if they fail at the next draw they are picked for use. This doesn't mean they cannot be successful, it means we cannot propose them because they are not collected using that "average" principle used in augmentative mode. They are different GATs in their characteristics and pick logic. By all means you can retain that GAT proposed in build-up and keep using it with Run Factor even if it may fail at the next draw, it may do good at the draw following it; but the build-up panorama will not propose it again as the smooth build-up chain of hits is broken.

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 14 guests