Suggestion for new option in winning numbers filter

[Trust]

I have a wish for a enhancement in the filter Winning numbers history:

In the winning numbers history filter it is an option box to
specify the differences in some of the columns.
I suggest another optional box for specifying the difference in
any of the columns. Example :The difference in minimum (of all
columns ) to maximum of all columns must be -5 to 5 etc.
This way we don't have to worry about in which columns our
limitations should act or hit.

Trust

[stan]

hmm, i'm not sure what you mean.

to specify maximum difference in any column you need to set the condition to 'the difference in 1 to 10 columns is -5 to 5'. then a ticket will pass the filter if at least one of the columns has the difference -5 to 5.

please clarify your post if i'm misunderstood.

[Trust]

I thougt that the filter worked like this:
all columns specified by user must have -5 to 5 to pass.
As you explained this filter do not work this way
Anyway my suggestion is to have an option like this:
In any number of columns selected by user -set minimum to maximum
value (-5 to 5 Etc) to pass.So if i want to i can set the filter to demand
that in any of the 10 columns there should be minimum 4 columns (or any other number of columns) to a maximum of 7 Etc. columns must be inside the limitations that i set (-5 to 5 Etc.)
This way this filter would be more flexible i suppose.

[Bobes]

Hi, I think that the required function is provided. Try the following please. Check box left from the "History index" row "0". Set the minimum and max wide enough (-100, + 43 from the actual sum in the first row). Check the radiobuton "Logical condition - and". Check the box left from "The difference in" and set number of columns "xx" to "xx" (for instance from 4 to 7) . Enter required value for difference "at least" "-yy" to "+yy" (for example -7 to +7). Finally check the choice "Matching tickets -Leave" and click apply. Resulting tickets (in package) must fulfil your request that in any 4 to 7 columns the difference from appropriate sum will be from -7 to +7. :vogel: How to perform check? Take any among the tickets from the processed package. Go to the WNHistory page. Ensure yourself that the condtions for WN Selection are the same you used for WN History filter. Enter the selected ticket into the editing windows next to the "Draw simulation". Click on "Update". Go to "Summary Table" and check values in the last two rows (the most bottom rows in listbox).

[Trust]

Ok -it seems to work the way i wanted but i did not understand why
the sum settings for column 0 must be moderated and not the other
columns?

[Bobes]

The filter performs in two parts so also the first part must be defined in order to work in correct way (at least one row must be checked; in fact it can be any among these 11 rows). Generally to avoid impact of the choice performed in such row ("0" or in any other row; first part of filter) the margins should be defined wide enough, thus when you select row labeled "0" the maximum + difference is +43 (in case all the last drawn numbers are drawn again) and the maximum minus difference is sum of the last 6 frequencies reduced by 43 in the sorted column "0" (see Number History Table explanation in Help).

[stan]

[quote=Hakl:1104151672]
The filter performs in two parts so also the first part must be defined in order to work in correct way (at least one row must be checked; in fact it can be any among these 11 rows). Generally to avoid impact of the choice performed in such row ("0" or in any other row; first part of filter) the margins should be defined wide enough, thus when you select row labeled "0" the maximum + difference is +43 (in case all the last drawn numbers are drawn again) and the maximum minus difference is sum of the last 6 frequencies reduced by 43 in the sorted column "0" (see Number History Table explanation in Help).
[/quote]

ehm, that's not exactly true. you can use the 'the difference in...' filter part without checking any rows in the table.

[tax]

Hi Stan and all,

This is going to be a bit long so bare with me people.

If I am correct, the Winning Number History filter idea is to approximate/guess the future SUMs of all columns after the next draw has occured. The narrow the range between each minimum and maximum on the same column will give you less tickets to play but include the winning ticket... correct?

The problem is that you do not know which column is going to go up and which is gong to go down and by how much. I have decided to look at the summary table and analyse each row to find out the number of occurances for different ranges. It turns out that out of 10 past draws I have:

1 to 5 columns with differences between -5 and +5
0 to 4 columns with differences between -10 to -6 AND 6 to 10
0 to 4 columns with differences between -15 to -11 AND 11 to 15
0 to 3 columns with differences between -20 to -16 AND 16 to 20
0 to 3 columns with differences between -25 to -21 AND 21 to 25
0 to 2 columns with differences between -30 to -26 AND 26 to 30
0 to 3 columns with differences lower than -30 (aka -45) but none greater than +30!

However, if you take greater ranges and join 2 adjacent ranges the following occurs 80% of the time:

3 to 8 columns with differences between -10 and +10
1 to 6 columns with differences between -20 to -11 AND 11 to 20
1 to 3 columns with differences between -30 to -21 AND 21 to 30
0 to 3 columns with differences lower than -30 (aka -45) but none greater than +30!

Note that the above ranges could be modified even further and they may be totally different for your own lottery!

So I have decided to setup my ranges in the minimum and maximum columns of every row from -50 to +30 but this range is too big of course.

And here is my suggestion: instead of having just 1 check box where you specify one range at a time between a minimum number and a maximum number of columns, I think it would be great to have several check boxes, all related with logical operator AND or OR where you can specify different minimum and maximum numbers of columns as well as different ranges.

An example could be as follow (check the parenthensis):

((1 to 5 cols range -5 and +5) AND/OR (0 to 4 cols range -10 to -6 & 6 to 10) AND/OR (3 to 8 cols range -10 to 10))
AND/OR
((0 to 4 cols range -15 to -11 & 11 to 15) AND/OR (0 to 3 cols range -20 to -16 & 16 to 20) AND/OR (1 to 6 cols range -20 to 20))
AND/OR
........

Got the idea??? :*)

Let me know what you think.

Cheers
Laurent

[stan]

interesting idea. but you can already setup such a filter using the compound filters in the beta 4.1.

but we'll look into this anyway...

[tax]

Hi Stan and all,

While explaining my previous posting I was using version 4 NOT 4.1 BETA :red:

I have setup the compound filter hoping that I have not mixed up the OR and the AND logical operator but my question is:

When running the Compound filter, what am I supposed to see on my screen? a message box with a porgress bar? or a spinning blue pizza attached to the mouse pointer?? cause I am having the later and I am not sure whether it is what I am supposed to see.

Cheers
Laurent

[stan]

compound filter is a filter like any other. so you should see a horizontal progress bar when using it.

try some simple compound filter first (e.g. odd/even + high/low) to see how it works.

if you think there's a bug in the wn history filter, pls email me the error.log file and also your compound filter database (in application's install folder, filtersfilters.db).

[tax]

Stan,

As usual, I did not go for an easy and simple compound filter. I am running a compound filter with 22+ Winning Number History filters. I have started at 1:00 AM and I think it will go for at least 24 hours cause I can almost count the tickets being filtered. It is processing 8145060 tickets (6 in 45).

The only way to have it run (the compound filter I mean) is to choose:

Filters -> Compound Filters -> Manager
and from the window to click the "Apply" button.

Cheers
Laurent

[stan]

a bit faster option would be to use the ticket generator together with this filter as the application doesn't have to perform so many read/write operations.

but it seems too slow anyway. i'll try to setup a similar filter and see if there's anything wrong or if i can do some code optimizations.

[Bobes]

Hi Laurent,

I agree with you in all what you wrote in the first part of your contribution. But I must observe that you wrote about only one part of the necessary decision process. You should take into account that columns in the WN history table are mutually affected. In fact only one of the columns is really important in your decision making process regardless which one it is. :vogel: Because even very accurate estimation in one column (difference +/- 1) will lead to relatively large rest of the package we should use the other columns to make selection more accurate. Thus the steps applied in decision making process should be as follows:

1) To decide in which columns you can make decision about the future orientation (negative or positive direction) and about the future absolute value in the best and easy way. To do this you can use
→ History differences table; this screen contains simulator (simulation button in the right bottom corner) so you can simulate up to 100000 draws by random generator. As you can see some columns are of small range; the highest difference is for example smaller than 25 and numbers are mainly in the top part of table. So in such case the probable orientation of the future deviation should be positive.
→ History charts (Sum charts and Deviation charts) here You also can estimate orientation and absolute value of the future deviation (in order to obtain better imagination you can use „Draw simulation button“ editing fields.

2) So if you decided about numbers for one column the values are predetermined also for the other columns. The smaller the range of margins the smaller the count of remaining tickets in the package. When you perform Statistics of such rest in the package, you can identify what numbers are the most frequent and/or what couples are the most frequent. (But you must be aware that results are usually of the type either/or (excluding when the rest is really very small)) - meaning that not all most frequent numbers are actually the winning ones.

3) As you wrote the number of columns with difference between +5 to –5 is usually from 1 to 5. It should be noted that we recognized for the most frequent situation the difference
–10 + 10 in 3 to 5 columns. If we take it for general rule, we have the first criterion to perform selection from the full package. When we say „in any 3 to 5“ columns we can obtain about half of the initial contents of the package. However using the history differences tables we can try to estimate which columns should have this small difference. Note the shape of the each individual column, pls. Usually majority of the numbers is in its top part. Regarding the fact that in each draw the maximum possible positive deviation is +43 (smaller if the first line of appropriate column does not contain at least 6 numbers) you can perform estimation concerning the +5/-5 deviation. (Either six numbers close to deviation with value 8 or prevailing count of numbers from the top part (4 to 5) with 1 to 2 numbers from the bottom part with bigger deviation etc.. For example if such columns contains more than 30 numbers in its top part the likelihood for the positive deviation is higher.

4) So if you decide (according to your letter) that 1 to 3 columns are to be with differences between –30 to –21 and 21 to 30, you can verify this decision from the point of view of the History differences table. You can identify whether it is possible at all and what conditions are necessary to fulfil your estimate. (In principle when you are able to say which columns are those with +5/-5 difference then in case of four columns the rest of the package should be small enough. The same applies also for large future deviations. Particularly in case of large negative deviations the applicable count of numbers is very small. Thus in certain cases you can estimate values for 5 columns only and when the margins are close to each other (for example +5/-4) you need not estimate remaining values at all. In certain cases when you use very small margins for +/- deviations trying to estimate the correct values in each column none of tickets even from full package could match such selection.

5) The +10/ –10 interval applied for each particular deviation is the condition to obtain rest in the package from tens to hundreds. Then you should apply any other mechanism of selection (for example tickets containing the first of the most frequent couples completed by tickets containing the second of the most frequent couples only (as you remember this selection corresponds usually to either/or logic)).


So based on the above mentioned I think the better way to perform correct selection is as follows:

→ Estimate for each column the conditions (maybe with their likelihood) under which the deviation could be strongly positive (more than +5) or neutral (+5/-5) or negative (less than –5 up to for example -15), or strong negative (less than –15).
→ Perform selection for the so called 'sure' columns (for example I decided that in columns 0, 3, 4 and 8 the future deviation is to be from –5 to +5 from the existing value and in the column 6 the deviation will fall by 45 in comparison with existing value.

In remaining columns you could leave margins without restriction (wide enough) in this first step.
Now you can analyze rest in the package (usually it is small enough to allow fast processing) concerning different possibilities for each column undecided so far with possible selection of representative tickets from each step.


Btw, as for your filter. In order to verify such filter lot of time is necessary, so this work was not done yet. However I would like to promise that I shall try it later with following report containing my final opinion.
At the first sight I would go as far as to say that some combinations (OR in particular) will lead even to full package.

Josef