Well, greetings to everyone. It's been a while since my last post but I have some good news to announce. In the past I used to talk about a system (named Wheel Generator [WG]- search older posts here f you want more info) that can construct coverings on demand and also incorporating constraints (filters) to the final outcome. This is the first time I have actual testing data to present, as it currently forms, and I'd like to hear your comments.
I'll use an 18,6,4,6=42 covering to illustrate some interesting observations. This covering was picked randomly for this example.
First, I plan to play with my 18 randomly selected numbers (lotto 6/49 game) which are: 3,6,7,8,12,15,19,23,24,25,26,28,30,34,35,39,43,46
I also plan to introduce the following filters: Sums accept 80-160, Odd/even accept 2-4 and Common accept 2-3 where my common set is: 6,7,8,24,25,26,28,30 (that means I want 2-3 numbers from this common set to appear in every ticket produced, if possible).
First I present a typical (18,6,4,6,L=1)=42 covering as found in the internet and applied my 18 numbers set to it:
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
In the above covering, after the * are displayed the columns [Sum/Odd-Even/Common] and in red the tickets that failed in at least one filter (in bold the filter failed). The above wheel offers the 4if6 100%, however it fails quite miserably to the filters requirements (21/42 of tickets pass the filters): Sums pass 35/42 (83.3%), Odd-Evenpass 36/42 (85.7%), Common pass 26/42 (61.9%).
WG, was set to produce the above covering from scratch with the requested constraints. All filters and coverage have been set to equal priority (50%) [think of this as boosting everything as much as it can get without degrading the importance of any of the constraints] and the produced covering was:
03 06 07 35 39 46 * 136,4,2
03 06 08 15 24 34 * 90, 2,3
03 06 15 25 30 39 * 118,4,3
03 06 19 23 26 30 * 107,3,3
03 06 26 30 43 46 * 154,2,3
03 07 12 15 26 43 * 106,4,2
03 07 19 23 24 25 * 106,5,3
03 08 12 26 34 35 * 118,2,2
03 08 15 25 26 43 * 120,4,3
03 08 23 28 30 34 * 126,2,3
03 08 24 28 35 43 * 141,3,3
03 12 19 28 30 39 * 131,3,2
03 12 25 30 34 43 * 147,3,2
03 19 25 28 39 46 * 160,4,2
03 23 24 26 34 39 * 149,3,2
06 07 23 28 34 43 * 141,3,3
06 07 24 25 26 28 * 116,2,5
06 08 15 23 28 39 * 119,3,3
06 08 25 34 35 46 * 154,2,3
06 08 26 30 39 43 * 152,2,4
06 12 19 25 43 46 * 151,3,2
06 12 23 24 30 35 * 130,2,3
06 15 19 26 28 35 * 129,3,3
06 24 34 39 43 46 * 192,2,2
07 08 12 19 34 39 * 119,3,2
07 08 12 23 43 46 * 139,3,2
07 08 15 19 30 35 * 114,4,3
07 08 24 25 30 39 * 133,3,5
07 12 26 28 35 39 * 147,3,3
07 15 23 25 35 46 * 151,5,2
07 15 26 30 34 46 * 158,2,3
07 19 24 28 34 46 * 158,2,3
07 19 25 26 34 43 * 154,4,3
08 12 19 25 28 46 * 138,2,3
08 19 24 26 35 46 * 158,2,3
12 15 19 23 34 46 * 149,3,1
12 15 24 25 35 39 * 150,4,2
12 15 24 28 30 46 * 155,1,3
12 23 25 26 28 46 * 160,2,3
15 19 23 24 26 43 * 150,4,2
15 25 28 34 35 43 * 180,4,2
19 23 30 35 39 43 * 189,5,1
The above covering offers 4if6 in 99.14% (missing 160/18564) and the filters requirements (33/42 tickets pass): Sums pass 39/42 (92.8%), Odd-Even pass 38/42 (90.5%), Common pass 37/42 (88.1%). That translates as we made 12 more tickets passing our filters
Now, although we don't have a complete 4if6 100% covering, possibly due to the equal priority and the constraints set, we see a good boost in the conditions set by the filters and a 'maximization' of coverage offered under these constraints. Regarding the 4if6 coverage, it might be an utopia to expect it to be 100% based on the filter constraints we have set, for the same amount of tickets required by a minimal construction without constraints (42 in this example). This is mainly because aminimal construction is quite tight to 'allow' many alterations and 'room' for further constraints (filters) and still maintain the 100% guarantee. Of course nothing tell us that such a covering doesn't exist. We could try and set the engine to give more priority to the coverage or alternatively we could add a few more tickets as as implified way to compete with the 100% requirement whilst retaining these constraints. My observation is that we do actually play more tickets which 'look-like-winning-tickets' when using such an optimization whilst maintaining a very high coverage ratio, compared to playing just a minimal covering and applying our numbers on it without any optimization. I'm looking forward to your comments.
cheers
lottoarchitect