Hello there,

i was wondering... i have a ~ 4000 tickets group with a nice covering for a hit 3 (5/45+PB, backtesting 300 draws).

Any ideas , how could i reduce to a ~ 100 tickets, still keeping the "hit 3" as much as posible?It is posible?

Btw, good luck with the new job, LA.

Br

Gunner

## filtering .. again

- lottoarchitect
- Site Admin
**Posts:**1450**Joined:**Tue Jan 15, 2008 5:03 pm**Location:**Greece-
**Contact:**

### Re: filtering .. again

Hi gunner39,

The main problem is that the definition of coverage is "problematic" when we have an arbitrary set of tickets.

You can read more about some issues regarding coverage computations so to get a better idea of the subject and its problems in this thread http://www.forumforfree.com/forums/inde ... owtopic=90

If you read the above thread, you'll probably realise that we cannot easily define a proper value for the amount of numbers included in our initial tickets group; to clarify this, we can always assume we have all the possible numbers, however this will produce coverage estimations which are generally of no use, especially if we actually have fewer numbers present in our group. These are some difficulties that have to be addressed. However, it is possible to create such a process but I can't really suggest what can this achieve.

The first to consider is that the produced outcome will contain only tickets from your initial tickets group, assuming we have solved the initial problem of what is the amount of total numbers appearing in our tickets and what to do in terms of coverage computation if fewer numbers appear.

The second part, is the actual process of finding which tickets to use from our initial tickets group that provide the best coverage (assuming we can compute a meaningful coverage due to the aforementioned difficulties). WG internal processes can help in this greatly but there is some way to reach this target and transform as required the construction process to support an arbitrary tickets group as a constraint. Of course, a greedy (and quick) approach is possible but this will provide a (quite) lesser quality result although still acceptable. Brute force is generally out of question because it will take forever to compute something useful. Again, all the above make sense only if we tackle the initial problems, thus at the moment I can't really say if it is possible to create such a tool which works on an arbitrary tickets group.

As you can see, there are several difficult issues to be tackled so to be able to produce a quality tool that can produce a near-optimal outcome. Keep in mind that such tools (probably using the greedy method) already exist when our initial tickets come directly from a wheel. This is a totally different situation so if you know of these tools already in other programs and you question why I say it is a very difficult task to tackle, just keep in mind that these tools are operating on a ticket set that comes directly from a wheel; not from an arbitrary tickets group. If I ever manage to tackle these difficulties, I'll add support for this and using WG's engine too for optimal (or near-optimal) results.

However, here comes a tricky question which many people do not realise when it comes to tickets elimination. I had a fight about this a couple of years ago with a developer of such a tool and the purpose and usefulness of such a ticket eliminator which operates in an existing wheel (there isn't really any other sort of eliminator at the moment which is based on coverage to my best knowledge) to reduce the total tickets and try to maintain a high hit ratio for a lower hit division. For example, let's assume we pick an 4if6 wheel which produces 1000 tickets. We find it quite large to play and we come across with such a ticket eliminator which tells us that it can reduce it and produce an 3if6 with much fewer tickets which will contain of course only tickets from the initial 1000. Of course we are delighted to hear such news and therefore trust it blindly as it guarantees it will maintain a high hit ratio of a lower division and still use only tickets from our initial tickets group. So far so good... Sounds too good to be true... Do you find any benefit in this process? Before reading on, think of it a bit.

I'll explain what I mean right away. First of all, let's consider the fact that we initially use an 4if6 wheel which we eventually filter after the application of the eliminator. If we think of this carefully, we can say right away that we have totally destroyed the reason we initially used the 4if6 wheel; which is the guarantee offered. That's a tragic mistake to remove even one ticket from a wheel which is the main reason to use a wheel in first place! So, let's move on and consider if we actually benefit anything by bringing this 4if6 down to a 3if6 wheel with fewer tickets. Again, the answer is no simply because the 4if6 wheel has predetermined tickets on which the 3if6 will be based on. Therefore, the produced 4if6 will definitely have several move tickets (because of the constraints imposed by the 4if6 tickets) than those really required to have an actual 3if6 wheel if we directly use such a construction that offers the 3if6 coverage. Another argument is that we can have parts of that 4if6 coverage too, since the tickets come from that initial wheel. Again, it is much preferable to construct an 3if6 + 4if6 wheel at the same amount of tickets produced by the eliminator. We'll cover more of 3#hits and better coverage of 4# anyway compared to this eliminator process. Of course, from another point of view it is a quick and dirty way to eliminate tickets and produce a low quality outcome (at least for me I think there are other much better ways to play the same amount of tickets produced) but the bottom line is: why use an 4if6 wheel in first place if we are about to ruin it by removing its tickets???

I really don't see any usefulness in such an elimination process and unfortunately people who develop these particular tools they throw dust in the eyes of people and make them think it is something valuable when in fact it is one of the worst tools ever devised (for the case of operating in an initial wheel only; arbitrary ticket sets are totally different since in this case we do not ruin an initial guarantee i.e the 4if6 above and obviously the tickets we have do not form a wheel in that sense to ruin. therefore securing a guarantee in this case is a very welcome process during the elimination of tickets). If you have any comments to favour or go against such eliminators or any of the above mentioned please feel free to participate.

Finally thanks for the wishes, I have already started in the new job, my 2nd week now. It looks good although it has lots of work. As soon as I settle down to my new place I'll resume work on WG and the rest too.

cheers

lottoarchitect

The main problem is that the definition of coverage is "problematic" when we have an arbitrary set of tickets.

You can read more about some issues regarding coverage computations so to get a better idea of the subject and its problems in this thread http://www.forumforfree.com/forums/inde ... owtopic=90

If you read the above thread, you'll probably realise that we cannot easily define a proper value for the amount of numbers included in our initial tickets group; to clarify this, we can always assume we have all the possible numbers, however this will produce coverage estimations which are generally of no use, especially if we actually have fewer numbers present in our group. These are some difficulties that have to be addressed. However, it is possible to create such a process but I can't really suggest what can this achieve.

The first to consider is that the produced outcome will contain only tickets from your initial tickets group, assuming we have solved the initial problem of what is the amount of total numbers appearing in our tickets and what to do in terms of coverage computation if fewer numbers appear.

The second part, is the actual process of finding which tickets to use from our initial tickets group that provide the best coverage (assuming we can compute a meaningful coverage due to the aforementioned difficulties). WG internal processes can help in this greatly but there is some way to reach this target and transform as required the construction process to support an arbitrary tickets group as a constraint. Of course, a greedy (and quick) approach is possible but this will provide a (quite) lesser quality result although still acceptable. Brute force is generally out of question because it will take forever to compute something useful. Again, all the above make sense only if we tackle the initial problems, thus at the moment I can't really say if it is possible to create such a tool which works on an arbitrary tickets group.

As you can see, there are several difficult issues to be tackled so to be able to produce a quality tool that can produce a near-optimal outcome. Keep in mind that such tools (probably using the greedy method) already exist when our initial tickets come directly from a wheel. This is a totally different situation so if you know of these tools already in other programs and you question why I say it is a very difficult task to tackle, just keep in mind that these tools are operating on a ticket set that comes directly from a wheel; not from an arbitrary tickets group. If I ever manage to tackle these difficulties, I'll add support for this and using WG's engine too for optimal (or near-optimal) results.

However, here comes a tricky question which many people do not realise when it comes to tickets elimination. I had a fight about this a couple of years ago with a developer of such a tool and the purpose and usefulness of such a ticket eliminator which operates in an existing wheel (there isn't really any other sort of eliminator at the moment which is based on coverage to my best knowledge) to reduce the total tickets and try to maintain a high hit ratio for a lower hit division. For example, let's assume we pick an 4if6 wheel which produces 1000 tickets. We find it quite large to play and we come across with such a ticket eliminator which tells us that it can reduce it and produce an 3if6 with much fewer tickets which will contain of course only tickets from the initial 1000. Of course we are delighted to hear such news and therefore trust it blindly as it guarantees it will maintain a high hit ratio of a lower division and still use only tickets from our initial tickets group. So far so good... Sounds too good to be true... Do you find any benefit in this process? Before reading on, think of it a bit.

I'll explain what I mean right away. First of all, let's consider the fact that we initially use an 4if6 wheel which we eventually filter after the application of the eliminator. If we think of this carefully, we can say right away that we have totally destroyed the reason we initially used the 4if6 wheel; which is the guarantee offered. That's a tragic mistake to remove even one ticket from a wheel which is the main reason to use a wheel in first place! So, let's move on and consider if we actually benefit anything by bringing this 4if6 down to a 3if6 wheel with fewer tickets. Again, the answer is no simply because the 4if6 wheel has predetermined tickets on which the 3if6 will be based on. Therefore, the produced 4if6 will definitely have several move tickets (because of the constraints imposed by the 4if6 tickets) than those really required to have an actual 3if6 wheel if we directly use such a construction that offers the 3if6 coverage. Another argument is that we can have parts of that 4if6 coverage too, since the tickets come from that initial wheel. Again, it is much preferable to construct an 3if6 + 4if6 wheel at the same amount of tickets produced by the eliminator. We'll cover more of 3#hits and better coverage of 4# anyway compared to this eliminator process. Of course, from another point of view it is a quick and dirty way to eliminate tickets and produce a low quality outcome (at least for me I think there are other much better ways to play the same amount of tickets produced) but the bottom line is: why use an 4if6 wheel in first place if we are about to ruin it by removing its tickets???

I really don't see any usefulness in such an elimination process and unfortunately people who develop these particular tools they throw dust in the eyes of people and make them think it is something valuable when in fact it is one of the worst tools ever devised (for the case of operating in an initial wheel only; arbitrary ticket sets are totally different since in this case we do not ruin an initial guarantee i.e the 4if6 above and obviously the tickets we have do not form a wheel in that sense to ruin. therefore securing a guarantee in this case is a very welcome process during the elimination of tickets). If you have any comments to favour or go against such eliminators or any of the above mentioned please feel free to participate.

Finally thanks for the wishes, I have already started in the new job, my 2nd week now. It looks good although it has lots of work. As soon as I settle down to my new place I'll resume work on WG and the rest too.

cheers

lottoarchitect

### Who is online

Users browsing this forum: No registered users and 1 guest