Some things about Wheel Generator

Talk about anything Wheel Generator related which doesn't fit in the other forums
Post Reply
V Dogg
Casual
Casual
Posts: 13
Joined: Wed Aug 26, 2020 2:34 am

Some things about Wheel Generator

Post by V Dogg » Fri Jan 01, 2021 6:01 pm

I think I am getting the Wheel Generator in its basic form, but I still have questions about it. Here is what I have done so far:

1. Set v to 20 (want 20 numbers).
2. Set k to 5 (lottery draws 5 numbers).
3. Set t to 4 (want at least a 4 number match).
4. Set m to 5 (want to match 5 numbers to get a 4 number match).
5. Leave Base Coverage at 1.
6. Leave % Coverage at 100.
7. Set b to 10 (only want 10 number combinations).
8. Leave Auto reduce unchecked.
9. Haven't touched any of the bias sliders.

Now my problem comes at 7 and 8. If I do it as stated and I check the best covering menu, the combinations don't change even after an hour or two of running it. Now if I set b to, say, 2000 like the help file suggests and check auto reduce, after about an hour or two it leaves me with about 100 combinations, which is unaffordable for me. Is there something I am doing wrong or are the combinations when b is set to 10 the combinations I should go with? Or do I need to let it run for a little longer until I get to something affordable? Thanks in advance.

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

Re: Some things about Wheel Generator

Post by lottoarchitect » Sat Jan 02, 2021 12:42 pm

Hi V Dogg,

the engine is not "fire and forget". First, the auto-reduce option is used in cases when we do not have somehow an approximation of b to start with. In that case, we could set an arbitrary high b value and enable the auto-reduce check-box. The engine will detect the surplus of blocks and remove them accordingly. After the bulk of blocks have been removed by the auto-removal operation, there is not much use for this checkbox, it has done its purpose.
A particular use of this checkbox is when you want open-cover constructions (less than 100% coverage). This is where this option shines most as it will automatically remove blocks as long as the coverage requested is achieved. So, if you want e.g. the best 95% cover, set your desired L% (or click on the text to enter a more precise % number) enable this auto-remove and let the engine run overnight. Also this check-box is useful in more complex coverings which involve filters where finding a proper b setting to begin with is impossible.
Typically however, if you have a source for a good b value, you use it instead. Such sources are wheel repositories where b is indicated. Check out LaJolla covering repository as a starting point but there are others around too.
https://www.dmgordon.org/cover/
and an older reference is Rade Belic's listings although most have been surpassed but still a good source for b values
https://rbelic.home.xs4all.nl/mainpage.htm

Now, about the actual optimization process. The user has to manipulate the optimization parameters. It is virtually impossible to reach a good quality wheel without altering the bias as needed. To keep it simple, use standard algorithm, tension bias always to 0 and we'll adjust only the expansion slider and bias multiplier. Initially have multiplier to x1 and bias to 0. Start the optimization. What we want here is this:

1) have the main coverage indicated fluctuate a bit up and down. The jumps should be small or big depending on the 1-block cover indicated at the bottom. So, if 1-block line suggests e.g. a value of 10 and you see jumps of like 20, this is too big. If jumps are like 1-3 or so, it looks more natural. Don't dive too much into that detail, it is just a guide and not applicable in all coverings but this is just to get an idea of how big jumps we should have more or less. Like, if 1-block suggests a value of 5000, a fluctuation of 1-5 is probably a small one.
2) give the impression is reaches the best coverage found (in the parenthesis) once in a while.
If you observe the above two conditions, we are good and no action is needed. We just wait for the engine to find better improvements.

Now, if we don't get any improvement after a while, or the conditions 1 & 2 above are not met, we need to take some action as this means the current optimization settings are not effective. The single most important setting is the bias expansion slider. If the main coverage fluctuation is quite above the best found and case 2 never occurs, we typically have to lower the bias slider. I usually do this in steps of 200 or 250. So, from the initially 0 value, I change it to -250 or so and continue optimization observing case 1 & 2 as usual to see when my next change to this control will be.
If the fluctuation is too small, we increase the bias slider in a similar manner, like +300.
The bias multiplier just multiply or lower the impact of the bias expansion slider. In small coverings like the above you attempt it will probably slay only to x1. Bigger values (x10-x10000) are used in very big coverings like having hundred or thousands of blocks or having a very large value indicated at the 1-block line at the bottom of the program. Smaller values (x0.1 and below) are available to give more precise adjustment to the bias expansion when we have moved the expansion slider and we are willing to keep searching. This is a situation that we should generally avoid doing and optimization is considered complete when we have moved the bias expansion slider quite to the left (like a value of -900) and minimal coverage fluctuation occurs (after we have gone through all the mentioned gradual bias adjustments). That means we have no more adjustments to make.

Typically x0.1 and below has lower operational value in normal coverings like the one you attempt but it is available to anyone who wants to keep searching and the x1 setting is not sufficient anymore. Where this setting (x0.1 and below) has actual value is when we build around filters. In this situation even the typical x1 setting might be too much and cause a large undesirable coverage fluctuation.

To understand the bias multiplier, assume a setting of x1. Going from bias expansion of 0 to 1000 (maximum value) is equivalent as doubling the bias effect. x10 and bias 0 is 10 times the impact of x1 and 0. x1 and -900 is equivalent to x0.1 and 0.

Once we covered how optimization works, to your real questions:
Now my problem comes at 7 and 8. If I do it as stated and I check the best covering menu, the combinations don't change even after an hour or two of running it.
The particular covering in fact needs quite many combinations. If you check at the bottom of the program, the 1-cover line at the end suggests a theoretical minimum like 204 blocks. This is actually a minimum theoretical value and most of the time, the real possible achievable can be double or triple or more of what this value suggests. So clearly, with just b=10 blocks total, there isn't much more that can be found. Along that line, also check the main coverage line, it actually states 3 values, the current coverage and in the parenthesis it suggests two other values: the first is the best coverage found so far and the other is the best possible coverage that can be achieved with the current b setting. With just 10 blocks in your covering, you'll see that your current best covering has matched that best possible coverage. Obviously there is nothing more that can be found in that case and therefore no further changes will occur at the covering.
Now if I set b to, say, 2000 like the help file suggests and check auto reduce, after about an hour or two it leaves me with about 100 combinations, which is unaffordable for me.
It is impossible to be left with just 100 blocks with the settings you have set. Recall, even the theoretical minimum for this covering is 204 blocks. From the Rade Belic's site, this covering 20,5,4,5 requires around 359 blocks - the record stated at this site - might have been improved a bit over the years but you get the point of how many blocks are needed.

V Dogg
Casual
Casual
Posts: 13
Joined: Wed Aug 26, 2020 2:34 am

Re: Some things about Wheel Generator

Post by V Dogg » Sat Jan 02, 2021 6:12 pm

Thanks so much for the explanation, but unfortunately I am still scratching my head at WG. I think I got GAT where I want it, but according to your explanation there doesn't seem to be a way to get WG down to a wheel which would be affordable. I may look into it more, but I am still confused. I appreciate you explaining it in detail, though, something others probably just wouldn't do. If only there were a video showing just how to use it as I am more of a visual person.

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

Re: Some things about Wheel Generator

Post by lottoarchitect » Sun Jan 03, 2021 11:29 am

The affordable aspect is the actual cost someone plans to play with. Consider the above wheel you describe v=20,k=5,t=4,m=5.
Current record for an 100% t=4 win guaranteed is around 350+ blocks and even the theoretical is 204 as indicated. This is mathematics, we cannot do something better no matter how or what we do. Now you set b=10, what WG will do is it will attempt to rearrange the blocks in such a way that it will provide the best coverage possible towards your t win using the space provided by those 10 blocks. This construction is very easy and you get it as soon as you press the optimize button. In fact, the maximum possible coverage that can be made in theory in a wheel v=20,k=5,t=4,m=5 with 10 blocks is only 4.9%. You know you have reached such a condition in WG when your current best coverage is the same as the best possible indicated in the same main coverage line. In this particular covering, WG indicates within the parenthesis () it made a covering with 14744 combinations missing and the best possible (also indicated in the parenthesis) is 14744 combinations missing. Obviously, there is nothing better to be found as we have found the best possible already. Check the manual for what those values represent at the progress panel, it will offer some more insight and explanation.

Obtained coverage less than 100% is what we call an open-cover wheel. In your attempt here, you construct an open-cover wheel with just 10 blocks and it can guarantee the t=4 win only 4.9% of the time - this translates as: if we match m=5 correct numbers from our set of v=20, we have 4.9% chance to have a t=4 win in a block among those b=10 we have generated. Making open-cover wheels to meet the budget is a very viable method. Quite often we can have e.g. 90% coverage requiring even half of the total blocks needed for the same 100% coverage wheel (achieving 100% coverage for a t win is also known as a close-cover wheel). The bottom line here is, requesting a t=4 win when picking 20 numbers in a k=5 game is too much for just only 10 picked blocks for simple coverings. As you can see, 4.9% t=4 guarantee is virtually meaningless.

You can introduce filters in your design to bring the cost down, depending on your ability to find proper filters to use. This is a technique where WG also shines. It is a more complex method but rewarding if you go that route.
viewtopic.php?f=17&t=654

Don't mess with that if you don't feel comfortable with the basic principles yet. Take your time, once you have a proper understanding of the basic concepts involved in simple constructions, introducing FD constructions is a step above - a big one really - but this is a good way to bring the cost down considerably. However, no matter what in a v=20,k=5,t=4,m wheel expecting anything good out of just 10 blocks is too much. Target for at least an 80% coverage, most go for 90% or 95% when they want to reduce costs and the more experienced ones try to make groups/matrix etc as described in the link above.

Post Reply

Who is online

Users browsing this forum: No registered users and 9 guests