Hi lottoarchitect
How about an algorithm that does something like the following.
One way to reduce the size of our ticket set in v2.2 is to go to the ticket listing, right click and delete tickets one by one. If we want to delete 10% of our tickets we should probably delete every tenth ticket (assuming the tickets are randomly sorted) to hopefully maintain a somewhat even distribution of our input numbers. Likewise, for 20% removal, delete every 9th and tenth ticket and for a 50% removal every alternate ticket. This is could be a laborious process with a large ticket set.
I am suggesting that this type of procedure be performed by algorithm. At the ticket listing. right click --- add a line that says "auto ticket reduction", click, see a little window where we can insert our reduction factor, click and Bingo!! LOL--sounds so easy!!
Going one step further --- for those large full abbreviated wheels where we do not have optimum reduced cover ratio's we could achieve "approximately" the same thing by performing the same type reduction as described above. That is, for instance, by taking 50% of a randomly sorted ticket set from a full abbreviated wheel we would have "approximately" a 50% "cover ratio" (very loosely defined). My only point in raising this issue is to give some sense of a workaround for those wheels where we do not yet have the optimum reduced cover ratio's. It would make those large wheels with their corresponding large ticket sets more amenable and manageable.
I look forward to your comments. Thanks for the extraordinary effort in providing us with the optimum reduced cover wheels.
Regards
Bobijohn
Hi Bobijohn,
I always try to avoid random behaviour in any process possible or at least try to reduce its implication. Your suggestion is a pure random behaviour as it is not based on any analysis and I'm sceptical about it. I could add such a system (which is indeed very easy to add) for just being available if someone wishes to use it but I'd rather look for alternative ways to reduce ticket listing size. I recognize that the demand for such a system is the need to remove more tickets when we have tried almost anything else in terms of filtering and still we cannot reach a desired budget. This is where the manual removal might come in, so the user can decide what to remove by himself. This is the only reason I could consider this random approach for inclusion (it doesn't cost me anything to add it anyway ). However, there might be other better ways to reduce ticket listings, beyond the normal filtering already available in v2.2.
In my terminology, you mean a close-cover abbreviated wheel. The problem with filtering abbreviated wheels is that very quickly ruins the guarantee of the wheel. The analogy is not linear and you can test this using covermaster. Simply load a wheel and remove one ticket at a time to see how quickly the coverage vanishes. Actually filtering abbr. wheels is one of the worst tactics someone can follow. The truth is that building an open-cover wheel to the desired ticket size offers much greater coverage compared to a filtered close-cover wheel to the same amount of tickets. This is the reason I include open-cover wheels in Lotto Architect (external add-on).
regards
lottoarchitect
Hi LottoArchitect
Of course, I agree with you 100% that this is a random approach. For the 50% case a User may just as well print their tickets, divide the pile in two then toss a coin to decide which to discard and which to keep. I suspect though that most users would intuitively prefer to keep every alternate ticket, in the 50% case, in the "hope" of having a "somewhat" even dispersion of their input number group. Anyway, the suggestion was just to automate a procedure that can already be performed. It has the benefit of providing some "structure" to the deletion process. To borrow a quote from Fox News over here - "we report--you decide" In the end a player should be able to play the Lotto any way they like. The job of the software is to make it easy for them to do that.
Thank you for this great response and, yes, I meant close-cover wheel(s). To remove just one ticket from a guaranteed wheel destroys the guarantee. I am fully aware that further ticket removal decays the guarantee in some "exponential" manner. So we are back to the question. What do we do to reduce our ticket set when all else fails?
This begs the question -- is there a way to reverse the process? By this I mean take the final ticket set and have the computer tell us what our final cover ratio is? Even approximately? Such a result would be most enlightening and probably very useful to the serious players. It may be quite unique--I certainly know of no other software that does this.
Regards
B
Well Bobijohn, you place an interesting question: how to remove additional tickets if we can't do this by any other logical reasoning (filters etc). I don't really have an answer for this unfortunately .
In wheels we can have the reports that indicate coverage information. In an arbitrary ticket listing, where all numbers can exist, we have to define the term "coverage" to produce such a report. In wheels, the parameters that affect the coverage are the total numbers in wheel, block size and match parameters and then we test the wheel combinations to the defined coverage combinations set. I haven't thought of this applied in an arbitrary ticket listing. Any suggestions on this?This begs the question -- is there a way to reverse the process? By this I mean take the final ticket set and have the computer tell us what our final cover ratio is? Even approximately? Such a result would be most enlightening and probably very useful to the serious players. It may be quite unique--I certainly know of no other software that does this.
regards
lottoarchitect
LA,
I can't offer any solution re what is the coverage on our remaining number set but I have a suggestion re removal of tickets that may have some structure to it. You have previously spoken about some final modifying process to number sets 'to make the tickets look like the winning tickets'. I am not sure what this really is or means and I certainly have no idea as to how it goes about its business, but assuming it cannot make every ticket look like a winning ticket why not reject those tickets that it can't (make look like a winning ticket). Perhaps this process has the capability of making every ticket look like the winning ticket, but if it can't.... then reject them.
I trust I am on the right bus here. Or for that matter - on the bus.
regards
relowe
Hi relowe,
unfortunately this 'to make the tickets look like the winning tickets' is not applicable in a arbitrary ticket listing. I'll try to explain why. When we setup a filter, we reject those values that we believe will not be the result of the next draw (which is a winning ticket!). Those values that we retain in "accept" status are those we expect as a possible result for the winning ticket, thus they are essentially "look like winning ticket" results. When we have setup all our rejection & number group filters, all the combinations that pass are already in a "look like winning ticket" structure simply because we have been accepted by all our filters. It is easy to understand that it is not possible to define additional filtering based on that idea as the filtering has already done.
Where this "look like the winning ticket' makes sense is in use with abbr. wheels (not full wheels). There we have a predefined sequence of pointer tickets -> predefined tickets once applied our numbers. As we actually cannot alter the pointer numbers, what we can alter is the order of our numbers (the re-arrangement feature). Using filters as a guide we can re-arrange our numbers to the pointer numbers in such a way that more tickets of our wheel are accepted by our filters. NOTE: we do NOT filter tickets here, we try to make the tickets pass our filters, using our numbers on a predefined sequence of pointer ticket. So, any ticket of the wheel that finally pass the filters is automatically considered "looks like a winning ticket'. Hope this makes the idea more clear.
cheers
lottoarchitect
Thanks LA for your explanation. Clearly I wasn't even on the bus and was really riding a bicycle up hill.
But the functionality to make tickets look like winning tickets is most interesting - I now understand what you are trying to achieve here.
Thanks again
relowe
Hi LottoArchitect
Just following up
This begs the question -- is there a way to reverse the process? By this I mean take the final ticket set and have the computer tell us what our final cover ratio is? Even approximately? Such a result would be most enlightening and probably very useful to the serious players. It may be quite unique--I certainly know of no other software that does this.
Sure LOLIn wheels, the parameters that affect the coverage are the total numbers in wheel, block size and match parameters and then we test the wheel combinations to the defined coverage combinations set. I haven't thought of this applied in an arbitrary ticket listing. Any suggestions on this?
I think you may have solved the problem yourself -- for the single open/close cover wheel cases anyway.
Consider this:-
1) Assume we have a set of input numbers (say N=20) and picked a 4 if 4 wheel (L=1) for 1083 tickets. We run Calculations 1 and save the tickets.
2) We go to calculations 2 and run the numbers groups. Say we now have 800 tickets to keep. We save the 800 tickets. The computer also saves the 283 discarded tickets.
3) We go to calculations 3 and run the rejection filters. Say we now have the 500 tickets to save. We save those tickets -- that is our final ticket set. The computer also saves the 300 discarded tickets. Now we have 583 discarded tickets.
Now we let the computer do as you have said above -- delete all 583 tickets one ticket at a time.
.The analogy is not linear and you can test this using covermaster. Simply load a wheel and remove one ticket at a time to see how quickly the coverage vanishes
This assumes of course that the computer has available all necessary parameters, eg block size match parameters etc to reconstruct the original wheel in Covermaster or, your own wheeling program.
I think you get the idea.
OK-- I still have enough cash to buy a bike and join relowe
Cheers
B
Hi Bobijohn,
I don't see how the coverage definition of wheels can be applied on an arbitrary ticket listing. Even the example you provide, does not give me a clue about how to define coverage in an arbitrary ticket listing. Can you give a more detailed example? Perhaps I'm missing something here. I assume by coverage you mean e.g. "how many chances do I have to hit a 4if4 provided I'll play this arbitrary ticket listing". Or do you mean something else by coverage?
regards
lottoarchitect
Hi LottoArchitect
Thank you for the kind reply. I just made my deposit on a bike so I guess I can stick my neck out one more time.
We use your wheel generator and create two ticket sets for an N=15 wheel. One with L=0.8 (it derives 219 tickets) and one with L=0.5 (it derives 137 tickets). We save those ticket sets to a file. We also write down the other parameters we used to create those wheels. Now the User goes to lunch--a looong lunch!! When he returns he has forgotten which ticket set belongs to which "L" (Forget for the moment that he knows because of the ticket set size). Meanwhile LottoArchitect has very studiously re-arranged the formula for the wheel generator. We input the same parameters as we used to create one of the wheels in the first place but, instead of solving for the ticket size and combinations we now use one of the above ticket sets as a matrix in the input and solve for L. If we have paired them correctly then the computer will run for a while (Solving for "L" iteratively or otherwise) and give us the matching original "L" If we have not given the computer the correct ticket matrix to match the input parameters it would tell us so quickly.
I think the above best describes the essence of the issue as I see it. If it cannot be done then we have obviously hit a mathematical roadblock. As you know, I am not a mathematician so please pardon my ignorance on these matters. Combinatorial mathematics is way over my head. However, let me say that if the above can be done then there may well be some future in pursuing the matter further.
With regard to the definition of cover-ratio I must admit to not having given it any further thought as we embarked deeper into this subject. My thoughts were more on the "L" parameter as it related to the combinations within a ticket set and not how to describe the outcome. That being said, I think you have defined rather well what I meant with your choice of the word "chance". Thank you. In general, as in my strategy presentation, I stay away from the words, probability, chance, odds etc because they seem to mean different things to different people -- particularly non mathematical/scientific folk. May I take this opportunity to suggest that these definitions (including cover-ratio as it pertains to these terms) be something you define on your website since they are so germaine to any game of chance including Lotto's? It may help all of us communicate a little better when discussing issues regarding the program.
Finally, the word "arbitrary" ticket set. Is a wheeled ticket set, before any filtering etc considered arbitrary? Or, does it become arbitrary only when we have removed so much as one ticket thereby destroying the guarantee.? To my mind a "pure" wheeled ticket is unique to the parameters which created it and is, therefore, not strictly speaking arbitrary. Although, in the overall scheme of things it may well be. Thanks for your help on this one.
Beyond what I have said here there is not much more I can add. Sorry this was so long.
Thanks for the opportunity to give this topic one more shot.
Regards
B
Well, I might then better describe what is the problem with an arbitrary ticket listing, compared to a wheel ticket listing.
When we design a wheel with N numbers, C block size and M the match parameter (M=least correct numbers we must hit from our N to win the P guarantee), this automatically identifies the combinations that have to be tested to evaluate the L parameter. There are exactly nCk(N,M) such combinations that have to be covered. It doesn't matter what is the block size C, only the N & M parameters required to define the combinations that need to be covered. To evaluate the L, all we have to do is to test each of these nCk(N,M) possible combinations if it is covered by at least one ticket in our wheel. The important thing to notice here is that we need to define the N & M in order to evaluate the L parameter, or in general the coverage ratio of our tickets. A wheel ticket listing is not arbitrary by the means we have the N & M (and the other parameters) defined which is essential to define the coverage.
Now, let's assume we have a random collection of tickets. This forms an arbitrary ticket listing because we cannot apply the above definition in these right away. We might have all the numbers present in our tickets which is the main problem of applying the above logic. We know the C value (the block size) and we can manually define the category parameters we are interested in e.g. M=4 & P=3. What about the N? We can define this by the means "find how many different numbers exist in our arbitrary ticket listing" and use this as the N parameter. 99% of the time, this N will be the total possible numbers allowed in our game, thus it is like having a wheel with N=49 for a 6/49 game. We can always evaluate a coverage ratio given the N,C,M,P parameters but on the other hand, does this makes any sense on an arbitrary ticket listing? To answer the last question, yes, if we provide an arbitrary ticket listing that directly comes from a wheel and we find the total different numbers that occur in our tickets (will be the initial N parameter of our wheel and rarely <wheel N), we can establish an N value (and manually set the M & P we are interested in). Then, we can evaluate the coverage L for this listing. The problem is that in general we have all the numbers appear in our listings.
regards
lottoarchitect
Hi LottoArchitect
Thank you for the expert explanation of the problem. Sorry--I misunderstood the issue -- just did not believe one could not solve for "L" in the wheeled cases. Of course you can. It is only when there is a random ticket set containing all the numbers (not a wheel) that there is no divisor on which to calculate a Ratio to determine "L". If that's the dilemma then I have finally got it!!
Thank you for your patience
Regards
B
Yes Bobijohn, this is the problem, we cannot define a proper value for N. We can always assume that N is the total balls in our game but the coverage ratio will be in general of no interest. In ticket listings that come from wheels, by definition we know the N parameter but in general we cannot establish a good value for N in arbitrary ticket listings. Only wheels have the property to contain an exact amount of numbers, which is essential for the coverage evaluation. And please do not ask sorry for something! You didn't do anything wrong
regards
Anastasios