JADELottery wrote: ``The wheel you've generated should have the additional information as follows: [....] 3.968254% Coverage of 126 Combinations``.
Thanks for adding your expert and practical knowledge to this discussion. Your step-by-step description of the behavior of your algorithm in the aforementioned discussion was very clear and helpful to me. (Thanks to Ramijami for pointing me to it.)
Could you explain the derivation of that percentage figure?
That particular wheel covers 25 of the possible 126 4-tuples, which is about 19.84%.
It also covers 46 of the possible 84 3-tuples, which is about 54.76%.
-----
Also, it does not seem like your algorithm makes any effort to derive an "optimal" wheel -- the minimum number of tickets to play.
How would we compute the theoretical minimum wheel for the t<m requirement?
The computation is straight-forward for the t=m requirement like my original (8,6,4,4)=b example. Using Excel nomenclature, it is ROUNDUP(COMBIN(8,4)/COMBIN(6,4),0) = 5.
(Of course, I know we might not -- probably cannot -- achieve that theoretical minimum, as "lotteryarchitect" noted. In fact, for (8,6,4,4)=b, I can demonstrate that b=7 is indeed the minimum (optimum); and there are 280 such 7-ticket wheels.)
Likewise, for (9,5,4,4)=b, it would be ROUNDUP(COMBIN(9,4)/COMBIN(5,4),0) = 26.
Obviously, the theoretical minimum is much smaller for (9,5,3,4)=b. Your algorithm generated b=5 in your example.
But I cannot predict that or a smaller theoretical minimum, if any.