Win History Filter Odd/Evens

[Bobijohn]

Hi Stan,

Would you please provide a brief explanation as to how the odd/even filter works on the "winning numbers filter." I think I understand it when applied on a line by line basis. However, I am having a problem with it when dealing with the "at least x of y condition". Also, does it work on just the sums pattern or just the differences pattern or both, and if so how?

On the win history table we can see the odd/evens correctly for the sums. However, the odd/even pattern for the differences is incorrect in that it shows the same pattern as the sums pattern. Obviously this is not true. Was this your intention?

Thanks, as always, for your help.

Bobijohn

[stan]

please read here (section notes, paragraph 6) and let me know if better explanation is needed:
http://www.expertlotto.com/en/help/en/f ... istory.htm

[Bobijohn]

Yes, I am very familiar with that particular Help page. It is so fundamental to this excellent program I almost have it memorized. LOL. Anyway I think it is paragraph 7 to which you refer, not 6.

Perhaps if you re-read my original posting with the aid of the following examples and pictures you will see my dilemma..

Pic_1 shows the WNH sums for the last draw. There are 4 even numbers and 7 odd. The O/E pattern is correct.

Pic_2 shows the WNH differences for the last draw. The corresponding O/E pattern is not correct. It is the same as in Pic_1. There are now 7 even numbers - counting zero as even.

Now to do some filtering. Skip the last draw ( so as to predict the next draw based on the information we know) and filter to ± 16 and O/E pattern as per Pic_1. Pic_3 Shows the settings. I chose at least 3

(small number) so as to keep the winning number. This is filter Run_1 Leaves 52347 Tickets with the winning number present. Pic_4 shows the settings for the second Run where we predict the precise O/E

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?

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. In fact, if you do the same Run_1 and then

use at least 8 of the 11 must be even you will get the correct looking output in the package statistics-Pic_7., but, of course, the winning number is not present. This shows the filtering is at least working but

from the above not correctly.

That is my delemna and the purpose of the request for further explanation. I have only dealt with the sums odd/evens here but feel that the same concepts should also work with the differences. Again, my

original question.

Stan, I will e-mail you all the above plus my backup .pack file so you can simulate the above. I believe everything is easily reproducible.

While you are at it please check my return e-mail address against yours - I believe it has changed.

Thanks again.

Bobijohn

[Bobijohn]

Sorry Folks --> the editing did not come out right. Here is the same message better edited

Yes, I am very familiar with that particular Help page. It is so fundamental to this excellent program I almost have it memorized. LOL. Anyway I think it is paragraph 7 to which you refer, not 6.

Perhaps if you re-read my original posting with the aid of the following examples and pictures you will see my dilemma..

Pic_1 shows the WNH sums for the last draw. There are 4 even numbers and 7 odd. The O/E pattern is correct.

Pic_2 shows the WNH differences for the last draw. The corresponding O/E pattern is not correct. It is the same as in Pic_1. There are now 7 even numbers - counting zero as even.

Now to do some filtering. Skip the last draw ( so as to predict the next draw based on the information we know) and filter to ± 16 and O/E pattern as per Pic_1. Pic_3 Shows the settings. I chose at least 3 (small number) so as to keep the winning number. This is filter Run_1 Leaves 52347 Tickets with the winning number present. Pic_4 shows the settings for the second Run where we predict the precise O/E 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?

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. In fact, if you do the same Run_1 and then use at least 8 of the 11 must be even you will get the correct looking output in the package statistics-Pic_7., but, of course, the winning number is not present. This shows the filtering is at least partially working but, from the above, not correctly.

That is my delemma and the purpose of the request for further explanation. I have only dealt with the sums odd/evens here but feel that the same concepts should also work with the differences. Again, my original question.

Stan, I will e-mail you all the above plus my backup .pack file so you can simulate the above. I believe everything is easily reproducible.

While you are at it please check my return e-mail address against yours - I believe it has changed.

Thanks again.

Bobijohn

Stan. Assuming this comes out correctly, please delete the first message

[stan]

[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:)

[Bobijohn]

Stan, Thanks for the quick and detailed response. You are truly amazing!!

It will take me day or two to digest your response and get back to you as I have another commitment to deal with here first. So, please keep the material as I will be back - probably along the lines that the O/E feature be uncoupled so that it can be used independently from the max/min condition.

Thanks also to Da80th for the original suggestion. This is a powerful feature which can substantially reduce the size of the final ticket set.

More later

Bobijohn

[Falcon]

Hi Stan,

Bobijohn has tweaked my interest in this filtering approach using O & E's, and particularly his latter comment about decoupling from the max/min conditions. From what I see and have briefly attempted to run is that the O/E filtering could be used effectively in a generic sense and can be done so simply on the basis of observation of the OE statistics in the last column (Odd/Even) of the WN History Summary table. Ticket removal is potentially quite powerful.
Thus I would support Bobijohn in his filtering approach here although I note he is still to get back to you on the subject.

r

falcon

[Jerzy]

Hello Stan, hello everyone,

When we work with WNH O/E patterns using WNH Sum filters, not only the proportion of odd and even sums but also their positions in the columns have significance, because they form a pattern.

This filter works OK and is very useful. A weak point of this filter is that only single O/E sum pattern can get filtered out at a time,
and the settings need to be entered in 11 columns manually.

"Decoupling" O/E sum pattern filter from the max/min conditions could be impossible (Probably it always must be "coupled", at least behind the scenes) and it would complicate further this complex filter.

The best method of decoupling the O/E sum pattern from the min/max condition would be a separate filter for the O/E sum pattern. This filter would be accessible from the Statistics. It would display in a table all passed O/E sum patterns or a range specified by the user. It would be possible to select one or more passed O/E patterns (even hundreds of them) and filter them out.

There should be a condition: "At least ..... to ..... columns must pass" (min = 0, max = 11) to adjust the power of the filter. (in my 6/45 game at least 3 to 9 columns must pass probably works best).

To deal with the proportion of odd and even sums in the pattern another filter could be created. This filter would look and work like ordinary O/E filter for numbers in a combination, but the range of settings should be from 0 to 11 instead of 0 to 6 (for pick 6 games).

Best Regards

Jerzy

[Bobijohn]

Falcon --> thanks for your interest and input.

Jerzy --> Brilliantly stated. That is exactly what I had in mind when I used the term "uncoupling." That is the need to create a separate filter just as you describe. Excellent!! That would do exactly what I was trying to achieve with various combinations of ticked and un-ticked boxes but could not do so the way the filter currently works. A big thank you to you Jerzy for describing the issues so eloquently.

Stan --> How about it? I believe a new O/E filter as so eloquently described by Jerzy has considerable merit - easy to use and promises a large reduction in tickets - just as Falcon observed. One thing I might add and that is to provide an O/E stat sheet similar to the current one for differences. Probably need to provide a grouping of the odds or evens separately since there are 2048 combinations. As with most stats, the objective would be to display the most frequent occurring combinations and when they last occurred.

Regards

Bobijohn

[stan]

yes, a 'dedicated' odd/even whn sums filter wouldn't be much work. perhaps joe implemented such a plugin already?:)

[Bobijohn]

Many thanks Stan.

I am really looking forward to seeing this new filter.

Bobijohn

[stan]

[quote=Bobijohn]
Many thanks Stan.

I am really looking forward to seeing this new filter.

Bobijohn
[/quote]

actually, i was hoping that joe would implement it instead of me as it is really easy...

[Jerzy]

Bobijohn,

Thank you for supporting my filter ideas.

Stan,

Thank you for accepting my idea of WNH O/E Sum Pattern filter.

I also mentioned something about building a WNH O/E Sum Proportion filter but it remained unnoticed. Probably my presentation of this filter was not informative enough.

There could be 12 groups depending on the count of odd or even sums in 11 columns (regardless of their positions).

O/E proportion for WNH sums could be 0/11, 1/10, 2/9, 3/8, 4/7, 5/6, 6/5, 7/4, 8/3, 9/2, 10/1, or 11/0. Some of these proportions could be filtered out.

On the surface this filter would look similar to the existing Odd/Even filter for numbers in the tickets, but it would be based on WNH differences.

I believe this filter is worth building, but I don't know how difficult could be its implementation or how much time it would take.

Regards

Jerzy

[stan]

[quote=Jerzy:1204124098]

I also mentioned something about building a WNH O/E Sum Proportion filter but it remained unnoticed. Probably my presentation of this filter was not informative enough.

There could be 12 groups depending on the count of odd or even sums in 11 columns (regardless of their positions).

O/E proportion for WNH sums could be 0/11, 1/10, 2/9, 3/8, 4/7, 5/6, 6/5, 7/4, 8/3, 9/2, 10/1, or 11/0. Some of these proportions could be filtered out.

On the surface this filter would look similar to the existing Odd/Even filter for numbers in the tickets, but it would be based on WNH differences.

I believe this filter is worth building, but I don't know how difficult could be its implementation or how much time it would take.

Regards

Jerzy
[/quote]

i went through old(er) items on my todo list and found this.
is this still valid? there already is odd/even wnh filter...

[Jerzy]

Thank you, Stan!

You have already implemented this as the WNH Odd/Even Counts Filter.

It is a simple but useful filter, and it works OK.

Regards

Jerzy