[quote=Bobijohn:1203868242]
pattern as shown in Pic_1. This now leaves 43638 Tickets with the winning number present. However, the corresponding package statistics do not reflect the intended pattern at all. See Pic_5. Should
they not all be E_O_O_O_O_E_O_E_O_O_E as per the filter condition? So what have we got?
[/quote]
pic_4 shows that you used option '3 to 11 columns must pass' so you'll get also odd/even patterns that doesn't meet the settings in the filter table
Let's take another approach.
Generate a new package. Filter as shown in Pic_3 above. That is Run_1. Since the O/E pattern described in Pic_4 is probably too precise to predict we now want to filter the sums so that we keep at least
3 of 11 ( remember there are actually 4 even sums) must be even. The settings are shown in Pic_6. This is Run_2. This leaves 43213 but the winning number is gone. However, a look at the package
statistics shows that only those tickets with at least 3 even numbers have been retained - except the winning number is not there and it should be per the criteria.
pic_6 shows that all the differences were +/-16 which do not meet the criteria from pic_2. column 0 is even sum but the diff is +24 (outside the filter range) so this combination gets filtered out and the jackpot is already gone.
summary:
* odd/even condition is applied together with min/max diff condition at the same row in the table in the filter window. logical AND applies
* at least x to y columns must pass applies to odd/even patterns as well (see above)
in other words, you must correctly predict the range AND the odd/even pattern, otherwise jackpot gets filtered out. the odd/even pattern should be used in conjunction with larger ranges only to compensate larger numbers of tickets left after filtering. (btw, it was da80th's idea i think:)