TRANSFERED FROM OLD FORUM
Please consider a Pick 4/35 +1/35 jackpot game.
After completing my analysis and generating a Ticket set I want to do one last filter operation. That is, for this lotto example, filter out all those tickets which have not had three numbers out of four in one line in the past. In other words, my assumption is that a winning four number ticket has a high expectancy that three of the numbers will have been drawn together before.
How do I do that?
Thanks for your help.
this has been answered here
The process needs some effort and sadly there is not a single global filter to be used for that particular purpose but I'll add it. This sort of filter is a special one and the structures required to support it do not exist in this version. Other special filters exist as well. Examples of special filters include those that do not have a definite probability for their events or making it to work with the rejection filters' general design structure is difficult, thus they have to be designed by other means.
I read what you reference above before asking the question and did not find the answer there.
The problem with using the common appearance filters for what I have in mind is that they work for only one column, that is one previous draw. If you try and do this for more than one draw (as in the case for deleting all previous tickets) then the first filter removes the numbers required for the second and subsequent draws. In other words, it does not do what I have in mind - except for one draw per filter run.
I do have my common appearance filters set up to remove all previous winning tickets for each of the Lotto's available here so I am familiar with the procedure for that case.
Anyway, based on your response I assume that what I have in mind can't be done in this version - even using the common appearance filters.
Thanks for the quick response.
Ok, if you know this filtering process, then might be better to give me a good example of what you want to achieve as I might have not understood it properly. Can you clarify this: "After completing my analysis and generating a Ticket set I want to do one last filter operation. That is, for this lotto example, filter out all those tickets which have not had three numbers out of four in one line in the past"? This sounds like a common appearance filter or a number group.
Thanks for your patience
Consider same Lotto --4/35 and ignore the Bonus Ball
Consider the last two winning draws 3-15-26-29 and 20-23-24-30
A full wheel would generate 70 combinations for these 8 numbers.
Removing the two winning tickets would leave 68 combinations using Common Appearances.
There are four ways I can generate three combinations from each of those two winning sets
I wish to filter the remaining 68 tickets so that those remaining must contain the numbers as listed above--that is, three numbers from each of the winning tickets.
Now, if you use the common appearances filter and insert "yes" on line 3 ("no" for all other lines) for that particular winning ticket you will get the correct answer of 16 tickets containing all three prior winning numbers. However, if you do not put "no" you will get combinations of 2/2 and 3/1 etc from the respective two draws.
Now move to the second column of the common appearances filter and do the same thing--leaving the first filter you just created active. The answer will be zero tickets retained. I think you will see the reason is obvious since it is now filtering after the first filter which eliminated the numbers that did not meet the first condition. That is at the second filter it is looking for numbers from the second ticket which were removed by the first filter -- so none exist.
In conclusion, I want my final set of tickets to contain 3 numbers that have been drawn as a group from prior winning tickets.
Hopefully, this helps.
Well, there can be a solution for your problem and is done via the number groups system.
All you have to do is to generate number groups that contain your 4 numbers of each of the tickets you want to use as a guide, and set the matching parameters to 0 & 3 only for each such number group. 0 will allow a particular ticket to be tested by other number groups if it happens not to contain any numbers from your selected number group and 3 ensures that if this number group is used, 3 of the numbers must exist in the ticket, otherwise it will be removed, so if the tested ticket has 1, 2 or 4 common numbers it will be removed.
Also generate a number group that contains all the numbers from all your guide tickets (past draws you want to use) and set the matching criteria to the maximum only (this is 4 for your type of game). Perform stage 2 calculations to filter your initial wheel ticket set. If I have thought of this correctly, the above should do the job I think but not quite sure yet, my mind is tired really . I'll give it a good though again tomorrow.
The above process is different from the common appearances filter in that is does operate in an OR manner.
Unfortunately, using the number groups does not work either. The results are similar to the common appearances filter.
Using the first ticket as a number group and ticking only 3 will provide the correct answer of 16 tickets. If the zero button is also ticked the result is 17 tickets because it includes the second winning ticket. This is all correct.
If you then add the second winning ticket as a number group the result is zero tickets retained. This number group is only looking at the results of the first number group, finds nothing that meets it's criteria and so eliminates the retained tickets from the first group -- resulting in zero tickets retained. Same as the common appearances filter.
I am sure you can see the problem so will not impose my thoughts on possible remedies.
Incidentally, I do believe this is a valid and powerful filter technique (given a reasonable size data base) and would like to suggest you consider it for inclusion in your future updates. I know you have asked for suggestions on filters elsewhere in the forum.
Thanks for your help.
Hopefully I had a better thought of this and found a solution.
This works for your particular Pick 4 game and has to be adjusted accordingly for other pick games.
All you have to do is to create 2 number groups, each one containing your winning past tickets and set the matching parameters to 0-1, 3-4 (not 2).
For your example create the following two number groups:
3-15-26-29 > matching parameters 0,1,3,4
20-23-24-30 > matching parameters 0,1,3,4
and filter your initial ticket set.
The number groups cannot have overlapping numbers and works even if your initial ticket list contain more numbers than your number groups. In every case, your remaining tickets will contain one of the 8 specified number sets and only them. However I haven't found an easy solution (if one exists) if the groups overlap in their numbers with the provided tools.
As you have noticed, we do not select matching parameter 2. If you think of it a bit, you'll see that if a group matches 2 numbers, then this means the other group(s) can only offer another two numbers to complete a ticket thus there is no way to form a ticket with 3 numbers from a number group, so we reject it. In any other matching case, a group can offer 3+ numbers so if one group matches the ticket in 1 number then there can be another that can match it in 3+ numbers, so we don't reject it right away until we find out that no number group can offer 3+ numbers (this is why we activate 0 & 1 matching for the groups). I have tested this and does provide what you look for.
This works for such a limited case -- provided as an example only as you requested and specifically chosen not to have overlapping numbers. As you point out one gets into trouble if there are overlapping numbers from group to group -- something I became aware of when playing number groups taken from the common appearances table. This topic we touched on elsewhere recently in the forums.
In fact, for this limited example the second number group is not required to yield the correct result if the 2 is not ticked.
The concept driving this technique is to be able to apply it to all the prior winning tickets as stated in my opening message. Obviously, in that case there would be overlapping numbers from group to group. Besides, it would be a daunting task to manually create all the possible groupings for all the prior winning tickets.
So while it works for this limited example it does not, unfortunately, really do what I have in mind.
Thanks again for the help.
Let me correct something I said above. Yes, you do need the second ticket grouping to yield the correct results of 16 tickets for this case.
However, that still leaves the overlapping number issue unresolved for this to filter to work across all the prior drown tickets.
Anyway, for testing purposes, I added the following group 7-16-27-30 to give a play set of 12 numbers out of 35 in this pick 4 game. No overlapping numbers.
A full wheel requires 495 tickets. Using the three number groups -- one for each set and leaving the 2 unticked filtered the 495 tickets down to 117.
However, since we are grouping 3 numbers I then ran a test against a 100% 3 if 4 wheel using the same 12 numbers. This wheel requires 26 tickets. I filtered these 26 tickets as above and came up retaining 7. Using Covermaster these 7 tickets provide a cover ratio of 42% for the 3 if 4 condition.
An abbreviated N=12 3 if 4 wheel with 8 tickets has a 53% chance of winning a 3 if 4 hits combination. There were no common tickets between this set and the set of 7 above.
So what does all this mean? I am not sure! Most filters seem to cycle. This idea of using three prior drawn numbers in selecting your ticket grouping for this pick 4 game is no exception. One just has to look along the three line of the common appearances table set to stats/value or delays to verify that. However, if it is cycling in your favor then the concept of filtering as explored here may improve your chances of getting a 4 out of 4 win or, at least leaves you a 42 % chance of a 3 out of 4 win with just 7 tickets.
Thought I would just add this for those readers following along since I had done the work anyway. It does illustrate, once again, the powerful analytical possibilities of this program.
LottoArchitect, or anyone else -->any additional comments you may have would be welcome.
You ask, we answer...if we know the answer!
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest