Development - Wheel Generator 1.5

[Maryland]

I noticed the web site is in construction stage for WG. Patiently waiting it's arrival.

[lottoarchitect]

I have uploaded new screen shots to the website for Wheel Generator.
I would also want to announce the availability of Wheel generator will be on this Friday 21 November.
Finally, all registered users of Lotto Architect are eligible for 1 year subscription, free of charge.

cheers
lottoarchitect

[mstrooba]

Hey LA,

That is very ggod news. Looking forward to seeing the system.
Rgds / mstrooba

[goop285]

this wheel generator is unbeatable i doubt if ever someone will create better lotto wheel software its absolutely genius!!!

[Simon]

[quote="goop285"]this wheel generator is unbeatable i doubt if ever someone will create better lotto wheel software its absolutely genius!!![/quote]

Yes, this wheel generator is superb compared to other wheel software....

[mstrooba]

Hi LA,

I found an interesting site that offers 9 plays (www.justservices.com).
Assuming your new design of WG will also show percentages for 3if3, 3if4, 4if6, etc.
Furthermore, would the new release of WG allow you to enter a percentage of coverage you would like to see and then generate the number of plays ?
mstrooba

[lottoarchitect]

Hi mstrooba,

building to a particular percentage will be added in the next update along with some other features such as auto-removal of blocks based on L%. The L% parameter in the current version participates at the theoretical minimum display only.
Wheel Generator offers a full coverages analysis of course.

cheers
lottoarchitect

[mstrooba]

Hi LA,

Yesterday , I 'd spent quite a bit of time in checking WG. I'm really stunned on its capabilities and the new release of WG should in actual fact increase your chances in winning a substantial amount.
Some questions :
* I don't think I'd understand following statement
Quote - Thus if the Total Points [v] =15 for a 6 ball lottery i.e. ([k] = 6) and a 4 if 6 guarantee ([t] if [m]) is sought then the block number [b] specified to ensure this guarantee should be at least 19 - unquote.
Why 19 ?
* Block cover : a/b (c) -th.min d where
Quote - a: how many of the c(v, m) internal m-size blocks a single generated block can cover -unquote . Not quite sure whether I understand. What do you mean with internal m-size blocks ?
*Quote - Thus the rule is simple, we cannot construct a covering with a match guarantee with fewer tickets to that which th.Min value indicates and so the parameters need adjustment to allow more tickets. Note that L-base coverage and L-% parameters in the left panel also affect this theoretical minimum.- unquote. WG allows you to continue generating wheels even if in the covering parameters (blocks) show a number which is lower than th.min. What are the odds that it will come up with a lower blocks that mentionned in th.min
* Improvements : point c
By moving the variability slider or changing from standard to extensive doesn't mean that the internal moves goes up to 100,000 and beyond..
* can you please elaborate on 'bad move '.
* The wheels I have tried to design take a very long time, even those with the smallest amount of blocks.
* What are the criteria that have been used to determine th.min. Is th.min eual to L1.
Thanks
Mstrooba

[lottoarchitect]

Hi mstrooba, to your questions:

Thus if the Total Points [v] =15 for a 6 ball lottery i.e. ([k] = 6) and a 4 if 6 guarantee ([t] if [m]) is sought then the block number specified to ensure this guarantee should be at least 19

This comes from covering repositories where the current known record for this particular covering c(15,6,4,6) = 19.
Two of the most well known and respected such repositories where you can obtain the required are:
http://www.ccrwest.org/cover.html LaJolla and
http://www.weefs-lottosysteme.de/systeme,en.htm WeEf's website

a: how many of the c(v, m) internal m-size blocks a single generated block can cover

When we set the [m] parameter for the covering, this defines combinations, each one having [m] numbers, that have to be tested against the blocks of the covering to determine the actual coverage obtained. There are exactly nCk(v, m) such combinations that have to be tested. This is covering theory. If our covering covers each of these nCk(v, m) combinations then we have 100% coverage offered by the wheel. When we say 'our covering covers each such m-combination' we mean that there is at least one block in our covering, that has at least [t] common numbers with the tested m-combination.

Thus the rule is simple, we cannot construct a covering with a match guarantee with fewer tickets to that which th.Min value indicates and so the parameters need adjustment to allow more tickets. Note that L-base coverage and L-% parameters in the left panel also affect this theoretical minimum.

The Th.Min value again is a covering design theory matter. This value shows that no matter what we try, it is impossible to construct a wheel that offers 100% coverage for the parameters we have defined which has fewer blocks than those indicated by the Th.Min. Thus, if you set the parameter to a lower value, you are constructing an open cover, which means e.g. 80% coverage. In fact, in most cases it is impossible to even approach the Th.Min value; the required amount of blocks will be higher. Thus, there are no odds for obtaining an 100% with fewer blocks to what the Th.Min indicates. I have expanded the Th.Min capability so to be able to observe the Th.Min for any rational setting of L & L%. Thus if you set L=1 and L%=50, this translates as the 50% of 1 or L=0.5 and the Th.Min value will show the theoretical minimum blocks required to construct a 50% covering for L=1.

* can you please elaborate on 'bad move '.

Assume you design a wheel in WG that has only the coverage engine activated; no filters or the additional coverage. Whilst observing the current coverage obtained by the currently constructed covering you will notice that this gradually reduces (which means we have an improvement) but occasionally will display a higher value compared to the previous value it had. This is a 'bad move' since we had previously a better covering in terms of coverage and now we have 'worsened' it. Although it might sounds illogical to allow such bad moves to occur, this is essential to produce high quality coverings at the end. The bias slider (and the multiplier) adjusts the frequency of occurrences for such bad moves.

The wheels I have tried to design take a very long time, even those with the smallest amount of blocks.

The most important parameter for the optimization is the bias slider. Each covering will require a different setting for this parameter and you'll get a better feeling for what to set at the bias in due time and experience gained. Which are the coverings you attempt to construct?

What are the criteria that have been used to determine th.min. Is th.min eual to L1.

The Th.Min value uses a complex equation which takes into account the following parameters of the covering: v,k,t,m,L,L%.

cheers
lottoarchitect

[mstrooba]

Hi LA,

Following parameters entered :
C(20,6,4,6)=26. L=1, L % =100. Th.min showed 26 so I've entered 26 in required blocks. No filters entered.
Variability bias set at 0 %. The programme ran for about 31' with no results on the combinations. I 've then changed variability bias at 20 % for 25' with no success.
I must be doing something wrong here.
mstrooba