Using Import as Mother Cover

Talk about anything Wheel Generator related which doesn't fit in the other forums
Post Reply
user2187
Getting used to it
Getting used to it
Posts: 7
Joined: Wed Dec 01, 2021 10:26 pm

Using Import as Mother Cover

Post by user2187 » Mon Jul 25, 2022 5:19 pm

I usually make a wheel like 20 5 then filter it using external software and import it in WG as mother cover then I optimize it to 20 5 4 5 (with auto-reduce blocks to L%) and it's reducing the number of tickets significantly, I can see the blocks counting down fast.

But now I am trying to apply the same on KENO style game, making a cover of 20 5, then filter it, then import it in WG to optimize to 20 5 5 10, but WG is not doing anything noticeable and sometimes is not responding.

What I need to do is to take all possible combinations of 20 5 then filter them to reduce the number of tickets then again optimize them considering that 10 numbers will appear in the set of 20, is there anything I am doing wrong?

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

Re: Using Import as Mother Cover

Post by lottoarchitect » Tue Jul 26, 2022 7:46 pm

Hi user2187, it doesn't sound like you do something wrong. I can point to the Options->Preferences and at the Optimization section set the focused setting to a small value or even 0 to see if this fix the issue. Older versions had this setting too high (like 10000) which could render optimization on 5if10 virtually stuck.
Another thing to look at is the bias you have set. Typically a 5if10 will require a higher bias adjustment, even including the use of bias multiplier like x10 or x100. Consult the manual on how to adjust these settings. The idea here is, you may not et improvements simply because the bias is too tight for the condition of the covering and 5if10 typically will require a higher bias compared to 4if5.
Finally, we cannot rule out the possibility the filtered set used as mother does not allow further reduction due to the actual blocks left in the mother to work with.
If nothing works, forward me (at the official e-mail) your generated blocks to check it out (both sets 4if5 and 5if10) alongside the settings you use to inspect the case.

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

Re: Using Import as Mother Cover

Post by lottoarchitect » Mon Aug 01, 2022 7:46 am

Hi user2187, I attach your e-mail for reference for other users to understand this discussion.
Hi Anastasios,

As per the post in the forum asking about the KENO cover optimization, I will explain here the problem using 35 6 6 10 instead of 20 6 6 10:
Lottery name: Canada Daily KENO 70/20 match 6 of 20

The scenario I am trying to do is the following:

If I want to take 70 balls it’s almost impossible to filter and optimize it due to the very large odds, so I took 35 numbers only (from 1 to 35) and chose pick 6 from those 35, I supposed that 10 balls will be drawn between 1 and 35, so the cover now is 35 6 6 10.

Now using math:

Combination of 35/6 = 1,623,160.

Odds of 35 6 6 10 according to math and WG = 1 / 7729

Means, theatrically it’s enough to buy 7729 tickets to win the “match 6”.

This means also that we compressed the full combinations from 1,623,160 to 7729 (210 times)

But if we buy 7729 tickets, the prize is only $1000, so we need less than 1000 tickets.

What I want to do is to filter the tickets, but filtering 7729 tickets is not possible because it’s already compressed and deleting any number will delete many combinations which might be needed, so the solution is to filter the full wheel first than importing it as mother cover to WG and optimize it using 35 6 6 10.

Let’s say we filtered the 1,623,160 tickets aggressively and got only 12,000 tickets, than we want to use WG to optimize these 10,000 tickets using 35 6 6 10, I know we cannot compress it 210 times but maybe we can get only small number of tickets (like 200), this is what I am trying to do, but WG is not responding.

I change the bias settings including “Bias Expansion”, “Bias Multiplier” and even “Search Strength” and "Bias Tension” but the progress is still very slow, and sometimes giving “out of memory” error.

If I try the same file with 35 6 4 6 for example, it’s working fine.

See below image for 35 6 4 6:
Image 82.jpg

As you can see the main coverage is 100% than it’s reducing the blocks, and it’s reducing them fast.

But with 35 6 6 10 the coverage is between 5% and 50% depending on the tickets (I thought in mother cover the percentage should start with 100%), anyway, the progress is very slow, the number of blocks will not start reducing until the coverage is 100% but it will not reach it so it’s all stuck.

I know that the tickets are very compressed so it’s not easy to reduce them but logically we should be able to reduce the number (not 210 times) but maybe 20 times.

Please see the attached file and advise me if I am misunderstanding something.

Thank you
Shadi
Hi Shadi, there is a bigger problem here which doesn't allow you to do what you are after.

What is a mother and its use
When we use a mother, what we do is to state to the program what blocks it can use to generate a covering.
The aim of WG in this case is to use as few blocks from that mother as possible to maximize the guarantee for the parameters requested. In all WG versions so far, this is possible when k=m. In all other cases having k<>m, what a mother do is only to define what blocks can be used for the construction.

Check this post here
http://forums.anastasios-tampakis.net/v ... 654&p=2791
What you want to do fall at the C) category discussed in this post (the evaluation of FD coverage). I do not rule out the possibility evaluation of mothers to be possible when k<>m. For now, the most meaningful use for mothers to perform block reduction is when k=m because we can evaluate the FD coverage.

To expand a bit more on what is needed here, you want to evaluate 35,6,6,10 as FD construction. This is a two-side issue. The FD evaluation must be done on 10-number blocks (what has to be covered) so obviously providing 6-number blocks as mother will not do this. Allowing evaluation of FD in k<>m cases at least require as minimum to provide an m-number set of blocks (which will be different from what a mother currently does in WG).

There are many new things to come in WG in the future, I hope one of them to be the possibility of this evaluation. So, in reality, what you see as coverage is the unconditional evaluation of the covering 35,6,6,10 you try to optimize and it is not possible to see the actual achieved % of that mother.

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

Re: Using Import as Mother Cover

Post by user2187 » Wed Aug 03, 2022 8:47 am

Thank you very much for the detailed information in the reply and in the referred link.
In that case, for KENO, is there any turn-around to optimize the number of tickets? because for match 6, theoretically it's enough to buy 7729 tickets to get a match instead of 1,623,160 (210 times reduction), it means there must be a way to reduce the filtered tickets (12,000 in my example) to a smaller number, but if WG doesn't accept m<>k then maybe there is a turn-around.

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

Re: Using Import as Mother Cover

Post by lottoarchitect » Thu Aug 04, 2022 8:30 am

I can't think of something to do at this point, but I have to state the theoretical minimum indicated assumes that each block in the produced covering covers uniquely some combinations and no other block in that covering covers any of those blocks. This condition is known as a "pack design" and almost all t <> m coverings cannot be done as pack designs. In reality, there is a huge overlap especially the higher the difference between t & m which results as a real actual achievable minimum to be 2x 3x 5x or more of the actual theoretical minimum indicated. So in practice, this "theoretically it's enough to buy 7729 tickets" in reality would require e.g. 15000 blocks or more (random guess but it wouldn't be far from reality). Unfortunately, estimating somehow that real minimum value is out of question.

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

Re: Using Import as Mother Cover

Post by user2187 » Sat Aug 06, 2022 8:59 pm

It's clear now, it seems that optimizing KENO tickets is not an option, better to try the normal filtered and optimized covers.
Thank you again for the information.

Post Reply

Who is online

Users browsing this forum: No registered users and 13 guests