Best Tickets
The filtering process always leads to some tickets remaining in the package. The number of these tickets can range from a few tickets only to several thousands of tickets depending on the type of used filters. If your estimates for filter parameters were correct then the tickets remaining in the package will include the Jackpot winning one and other tickets matching the Jackpot in 5, 4 or 3 numbers.
Why use the Best Tickets filter
- A) The results of Best Tickets filter can lead to several groups of similar tickets. It happens when the starting package is too large or when previous filtering steps were not accurate enough (e.g. Min/Max margins were too big).
This problem can be resolved in many ways, e.g. try using any other filter. It is recommended to use a filter that applies in a generic fashion (Odd/Even, High/Low, Sum Root etc). The best choice seems to be Sum Root filter because of its almost uniform distribution. You can also select up to three tickets from these groups.
It is important to apply generally valid filters only. For example filter Match Package is not suitable because it will favor the first ticket occurrence that matches the filter condition. Naturally you can use Package Statistics page, which provides an extensive set of many supporting parameters. It is recommend to use Sum Root because if your estimates are not correct you can still keep a high chance of winning a higher prize (usually match in 5) while reducing the package contents by a factor of 9.
It is obvious that when a large original package (e.g. 50000 tickets) contains the Jackpot winning numbers (match 6 = 1x, match 5 = 179x, match 4 = 2158x ..) then the Sum Root filter can divide it into nine parts of the same size and each part will have approximately the same number of match 5 tickets. For example estimating Sum Root = 3, while the actual correct Sum Root is 4 still maintain a chance for Match 5 prize.
- B) Usually after selecting 50 Best Tickets you can see the groups of tickets at one location on the screen on Visual Package page indicated by columns of continuous graphics. If you highlight these columns (for example four of them) and click Total Match button you will see a table with a detailed break-down how many tickets in the package match those four numbers.
If there are more such groups it is either due to large original package (relaxed filtering conditions) or due to incorrect Winning Numbers History margins. Obviously only one ticket is the Jackpot winning one therefore you should chose up to three tickets from each group to keep your chances for smaller winnings at least.
- C) For those who prefer their gut feelings in decision making process it is recommended to use option Use Package Tickets at the bottom part of WN History Page. Then you can simulate WN History value with tickets from the package step by step using all available support provided by History Differences tables, chart etc. You can base your decisions on visual perceptions, however this procedure can be too subjective.
On the other hand even this procedure has features which are generally valid. It is for example the removal of all tickets containing all 6 numbers (6 is an example - you can chose 5 or even 4 which are more strict conditions) from the bottom part of any or each History Differences table. You can also take into account that 4 numbers from one row is rather rare case etc. In addition you can use StdDev chart (History Charts - the last row in Chart Options window and Summary Table - column StdDev (Diffs)). When you expect a high Standard Deviation value then you should favor 3 to 5 columns in +/-10 range to the usually applied condition of 4 to 6 columns in +/-10 range. It may also mean that you should expect more than one large difference (WN History filter) for the next draw. Therefore if you started your filtering with the condition of +/-10 range in at least 4 to 7 columns you should repeat the filtering with condition of at least 3 and at most 5 columns in the +/-10 range.
- D) In case you get more than one group of tickets after Best Tickets filtering, the best procedure may be to take all numbers from these groups and generate a full wheel for them and repeat the filtering the same conditions. You can also use Simulation tab on History Page (click ">" button in SImulation Tickets field and chose Package) to simulate this wheel. Then you can use values from Avg column as the starting values for Min / Max margins in the WN History filter. If you guess the reduced set of numbers (for example 25 to 32 numbers) correctly - it includes the six winning numbers - than you can use margins from +/-5 to +/-7. Usually 8 to 11 columns match these conditions even when applied to the full list of all combinations. You will get a smaller package then that you filter for 10 Best Tickets to avoid groups of similar tickets.
- E) It is also possible to divide large package to smaller parts (e.g. use Sum Root filter). Then select for example 30 Best Tickets from each group. Join all filtered groups into the package and filter for 10 Best Tickets again.
If you select for example 50 Best Tickets from a large package and then filter the result again for 10 Best Tickets the remaining tickets may be very distorted. Dividing the large package into smaller parts can prevent this distortion - however not completely.
- F) The main reason for implementation of Best Tickets filter was to prevent overlooking of some phenomenon in large packages when the lottery strategy focuses on one set of tickets only. It can happen in especially for large packages resulting from full wheels when numbers are spread through whole range almost uniformly. In such cases the package is sorted so you can easily miss something important.
Note: Even though the Best Tickets filter is primarily intended for filtering of results of WN History filters, it can be applied to any package. However you should have a clear idea of what the original package is like and whether the package can contain groups of similar tickets at all.
Naturally you can also use Best Tickets filter to make a bet from tickets with maximum coverage of the given package regardless whether the package contains or does not contain groups of similar tickets.