Theory of Covering Designs (Wheels)
A minimal covering design aims to offer to the player a means of achieving a predetermined guarantee when a particular condition is met. The purpose of coverings is to allow players to use more numbers and still maintain a reasonable cost of playing their tickets (or blocks in covering design terminology). Minimal coverings additionally aim to minimize the cost of playing. Some basic theory first to get you started in the analysis following:
A minimal covering is defined as c(v, k, t, m, L) = b where
[v] - The total numbers we want to play with (i.e. 20 numbers)
[k] - The size of each block to play - i.e lotto games that draw 6 numbers have [k] = 6
[t] - The guarantee we aim to achieve - i.e. how many minimum correct numbers we want to have in at least one of the proposed tickets generated by our covering.
[m] - How many minimum matched numbers we expect to have from our set of [v] numbers compared to the actual numbers of the draw - i.e. [m] = 5 means we believe we'll have at least 5 correct numbers from our set of [v] = 20 numbers which are the same to those drawn by the lottery commission. If this [m] condition is fulfilled, then we'll have at least one block in our covering that offers at least [t] correct numbers.
[L] - This is a multiplier of [t] - translates as how many times we want to have [t] fulfilled or in simple words how many different blocks in our covering will offer the [t] guarantee (always assuming [m] is fulfilled). If [L] = 1, it is usually omitted from the covering expression i.e. c(v,k,t,m) = b implies [L] = 1.
[b] - The total blocks required to play.
For example, the current record of an c(20,6,4,5, L=1) = 145 requires 145 blocks to be played. If we manage to have at least [m] = 5 correct numbers in our set of [v] = 20 numbers, when compared to the actual numbers drawn, then we are guaranteed to have at least one ([L = 1]) block among those 145 that will have at least [t] = 4 correct numbers to those drawn. Please note that this is a minimum guarantee. We may (and usually) have more than [t] numbers in the winning block or more blocks that offering the guarantee [t]. Ok... enough of this. Let's get to a real example ...
AN EXAMPLE OF COVERING APPLICATION FOR REAL PLAY
Let's assume we want to play a covering for an 6/49 lotto game. Obviously we'll look into coverings with [k] = 6. We also made our analysis and decided that we want to play with the following [v] = 18 numbers : 3,6,7,8,12,15,19,23,24,25,26,28,30,34,35,39,43,46.
Also, let's assume we made some analysis to the history of our lotto game and decided that we do not want to play any tickets that have sums outside the range of 80-160, having 2-4 odd numbers in each block and finally we want 2-3 numbers to appear in each block from the set 6,7,8,24,25,26,28,30. It is a common practice to use filters such the aforementioned because experience and real history data show that values outside these ranges are rare to occur, thus we aim to avoid playing 'improbable' occurring blocks - or my favorite quote "not having a look-like-winning-ticket shape". Of course users are free to pick any ranges or sets of numbers suit their tactics best but it is apparent that filters such as sums, odds or common numbers are very useful and desirable to have.
For the sake of this example, we hope to match at least [m] = 6 numbers and we want to guarantee at least one [t] = 4 win. That translates as we'll use an c(18, 6, 4, 6) = 42 minimal covering (the required amount of [b] = 42 blocks can be found in covering repositories - links at the bottom of this page).
A typical c(18, 6, 4, 6) = 42 as found on the internet is presented next, with our [v] numbers selection applied to the covering. The result obtained was:
Blocks |
Sum |
Odd |
Common |
03 - 06 - 07 - 08 - 12 - 15 |
51 |
3 |
3 |
03 - 06 - 07 - 19 - 23 - 24 |
82 |
4 |
3 |
03 - 06 - 07 - 25 - 26 - 28 |
95 |
3 |
5 |
03 - 06 - 07 - 30 - 34 - 35 |
115 |
3 |
3 |
03 - 06 - 07 - 39 - 43 - 46 |
144 |
4 |
2 |
03 - 08 - 19 - 25 - 30 - 39 |
124 |
4 |
3 |
03 - 08 - 23 - 26 - 34 - 43 |
137 |
3 |
2 |
03 - 08 - 24 - 28 - 35 - 46 |
144 |
2 |
2 |
03 - 12 - 19 - 26 - 34 - 46 |
140 |
2 |
1 |
03 - 12 - 23 - 28 - 35 - 39 |
140 |
4 |
1 |
03 - 12 - 24 - 25 - 30 - 43 |
137 |
3 |
3 |
03 - 15 - 19 - 28 - 35 - 43 |
143 |
5 |
1 |
03 - 15 - 23 - 25 - 30 - 46 |
142 |
4 |
2 |
03 - 15 - 24 - 26 - 34 - 39 |
141 |
3 |
2 |
06 - 08 - 19 - 28 - 30 - 46 |
137 |
1 |
4 |
06 - 08 - 23 - 25 - 34 - 39 |
135 |
3 |
3 |
06 - 08 - 24 - 26 - 35 - 43 |
142 |
2 |
4 |
06 - 12 - 19 - 25 - 34 - 43 |
139 |
3 |
2 |
06 - 12 - 23 - 26 - 35 - 46 |
148 |
2 |
2 |
06 - 12 - 24 - 28 - 30 - 39 |
139 |
1 |
4 |
06 - 15 - 19 - 26 - 35 - 39 |
140 |
4 |
2 |
06 - 15 - 23 - 28 - 30 - 43 |
145 |
3 |
3 |
06 - 15 - 24 - 25 - 34 - 46 |
150 |
2 |
3 |
07 - 08 - 19 - 26 - 30 - 43 |
133 |
3 |
4 |
07 - 08 - 23 - 28 - 34 - 46 |
146 |
2 |
3 |
07 - 08 - 24 - 25 - 35 - 39 |
138 |
4 |
4 |
07 - 12 - 19 - 28 - 34 - 39 |
139 |
3 |
2 |
07 - 12 - 23 - 25 - 35 - 43 |
145 |
5 |
2 |
07 - 12 - 24 - 26 - 30 - 46 |
145 |
1 |
4 |
07 - 15 - 19 - 25 - 35 - 46 |
147 |
5 |
2 |
07 - 15 - 23 - 26 - 30 - 39 |
140 |
4 |
3 |
07 - 15 - 24 - 28 - 34 - 43 |
151 |
3 |
3 |
08 - 12 - 15 - 19 - 23 - 24 |
101 |
3 |
2 |
08 - 12 - 15 - 25 - 26 - 28 |
114 |
2 |
4 |
08 - 12 - 15 - 30 - 34 - 35 |
134 |
2 |
2 |
08 - 12 - 15 - 39 - 43 - 46 |
163 |
3 |
1 |
19 - 23 - 24 - 25 - 26 - 28 |
145 |
3 |
4 |
19 - 23 - 24 - 30 - 34 - 35 |
165 |
3 |
2 |
19 - 23 - 24 - 39 - 43 - 46 |
194 |
4 |
1 |
25 - 26 - 28 - 30 - 34 - 35 |
178 |
2 |
4 |
25 - 26 - 28 - 39 - 43 - 46 |
207 |
3 |
3 |
30 - 34 - 35 - 39 - 43 - 46 |
227 |
3 |
1 |
TOTAL QUALIFIED BLOCKS 21 / 42 [50%] |
PASS 35/42 [83.3%] |
PASS 36/42 [85.7%] |
PASS 26/42 [61.9%] |
What can we observe from the above table? The fields marked in red fail to the filter conditions extensively and it is quite obvious that this covering as it is, even if it offers the 4if6 guarantee 100%, is not capable to approach the other desired constraints. This is more or less true whichever covering you may try as found on the internet. The reason is very simple: these coverings are not designed with filters in mind and they cannot be adjusted to fulfil such constraints beyond the 100% coverage. They are static and completely inflexible. The conclusion is that, although we are guaranteed the 4if6, we play a lot of tickets that do not conform to the desired properties of "look-like-winning-tickets" as defined by our filters, since we have set the filters to what we assume a winning ticket should look like. In our case the sums, the odd and the common filters define what is a "look-like-winning-ticket" since we expect the outcome of the next draw to satisfy these filters. This is the major drawback of static coverings and unfortunately there is nothing we can do about it. We cannot replace any of the failing tickets with others without ruining the guarantee. Even if playing just single blocks, I doubt anyone would like to spend money on tickets such as 03 - 06 - 07 - 08 - 12 - 15 or 30 - 34 - 35 - 39 - 43 - 46 or even 19 - 23 - 24 - 25 - 26 - 28 which are common in static coverings. However we are enforced to play these simply because if we don't, the covering cannot offer the guarantee as well.
So, what can be done? There is a solution, which now has a name..
AN EXAMPLE OF WHEEL GENERATOR IN ACTION
The next covering comes from the process of Wheel Generator, requesting the desired filters sums/odd/common and coverage as described earlier to be taken into account. The produced covering was:
Blocks |
Sum |
Odd |
Common |
03 06 07 26 34 39 |
115 |
3 |
3 |
03 06 08 12 39 43 |
111 |
3 |
2 |
03 06 08 25 35 46 |
123 |
3 |
3 |
03 06 15 30 35 39 |
128 |
4 |
2 |
03 06 23 24 28 39 |
123 |
3 |
3 |
03 07 08 15 23 46 |
102 |
4 |
2 |
03 07 12 25 28 46 |
121 |
3 |
3 |
03 07 19 24 30 43 |
126 |
4 |
3 |
03 08 19 23 25 34 |
112 |
4 |
2 |
03 08 24 26 35 46 |
142 |
2 |
3 |
03 12 15 24 25 34 |
113 |
3 |
2 |
03 12 23 26 30 46 |
140 |
2 |
2 |
03 15 25 28 34 43 |
148 |
4 |
2 |
03 19 23 26 28 43 |
142 |
4 |
2 |
03 19 28 30 34 46 |
160 |
2 |
2 |
06 07 12 15 19 23 |
82 |
4 |
2 |
06 07 12 23 24 35 |
107 |
3 |
3 |
06 07 15 28 43 46 |
145 |
3 |
3 |
06 08 23 25 34 46 |
142 |
2 |
3 |
06 08 25 26 28 30 |
123 |
1 |
6 |
06 12 19 28 34 35 |
134 |
2 |
2 |
06 15 19 24 26 46 |
136 |
2 |
3 |
06 19 24 30 34 43 |
156 |
2 |
3 |
06 23 25 26 35 43 |
158 |
4 |
3 |
07 08 12 26 34 43 |
130 |
2 |
3 |
07 08 19 28 35 39 |
136 |
4 |
3 |
07 12 24 30 39 46 |
158 |
2 |
3 |
07 15 26 30 34 35 |
147 |
3 |
3 |
07 19 24 25 35 46 |
156 |
4 |
3 |
07 23 24 26 34 35 |
149 |
3 |
3 |
07 23 25 30 34 39 |
158 |
4 |
3 |
08 12 15 30 35 43 |
143 |
3 |
2 |
08 12 23 24 28 43 |
138 |
2 |
3 |
08 15 24 25 39 43 |
154 |
4 |
3 |
08 15 24 28 34 39 |
148 |
2 |
3 |
08 19 23 26 30 39 |
145 |
3 |
3 |
12 15 19 25 30 46 |
147 |
3 |
2 |
12 15 19 26 28 39 |
139 |
3 |
2 |
12 19 25 26 35 39 |
156 |
4 |
2 |
15 23 24 28 30 35 |
155 |
3 |
3 |
23 34 35 39 43 46 |
220 |
4 |
0 |
25 26 28 39 43 46 |
207 |
3 |
3 |
TOTAL QUALIFIED BLOCKS 39 / 42 [93%] |
PASS 40/42 [95.2%] |
PASS 41/42 [97.6%] |
PASS 40/42 [95.2%] |
The previous static covering returned |
|||
TOTAL QUALIFIED BLOCKS 21 / 42 [50%] |
PASS 35/42 [83.3%] |
PASS 36/42 [85.7%] |
PASS 26/42 [61.9%] |
Improvements of Wheel Generator compared to static covering |
|||
18 |
5 |
5 |
14 |
Now, although the outcome isn't an 100% 4if6 (missing 60/18564 -> 99.67% 4if6) due to the severe constraints requested, we are actually quite close in achieving this. A loss of 0.33% in coverage has gained us an improvement of 43% more blocks qualifying based on our filters! And needless to say, this translates as having more exposure to having more numbers in the same blocks, since more blocks pass the "look-like-winning-ticket" test! It may also be possible to finally construct an 100% covering and still maintain those quite higher successes on the filters as well if we let the engine run for more time, or simply by adding a couple more tickets to fill the missing coverage gap. Considering that filters such as the common filter (known as Groups in WG) are quite demanding and observing that we actually managed to produce a covering with so high qualification properties, I consider the outcome outstanding for the same amount of tickets required for the same minimal covering without any constraints! The important to notice is that now we have a vast improvement of the formation of our generated tickets. We have increased the amount of qualifying blocks to play by 18 and still maintain a very high coverage ratio! Additionally, due to the "antagonistic" nature of the various filters and the coverage, there can be a few blocks that simply cannot be made fit in all requested constraints. WG recognizes this situation and attempts to concentrate all such failing situations in as fewer blocks as possible (these filter-failing blocks are used to benefit the overall coverage however!). Now imagine what this engine can do for you...