4.1 BETA

[stan]

[quote=Maryland]
Build 423 didn't fix the match winning numbers filter when trying to add it to compound filter.
[/quote]

alright, i found one problem in the match winning numbers filter. when the 'all draws' option is selected then there are problems with the filter. 'first X draws' or 'last X draws' options are fine.

is this the problem you're describing or is there something else?

[stan]

[quote=Trust]
Could the compound filter be made more flexible if it was designed like this ?:
Minimum x to maximum y of the selected filters must pass to be accepted.
As the compound filter works now the closest to this would be to set
up the filter like this:Filter A or filter B and filter C or filter D and so on.
But this way the filter will fail if any of the OR groups don't make it.
[/quote]

good idea but it doesn't fit the compound filter concept too well.
how about introducing a new sub-class of compound filters, called e.g. 'list fiters' where the sub-filters will be listed without and / or conditions and instead there'll be an option to specify 'at least 1 to X filters must pass'?
and of course you'll be able to use 'list filter' as a part of a compound filter and vice versa.

btw, is there a better (one word) english term than 'list filters'?

[stan]

[quote=zz]
Step1: Making the compound filter using at least one match file filter.
Sttep2: Generate all possible combinations using the compound filter and - it doesn't work (immediate error message, where is strange sometimes I'm getting error filtering and sometimes error loading tickets). Here is also strange If the compound filter didn't have the match file filter it would work. If the match file filter was used separately(alone, not in the compound) it works.
[/quote]
i see the error log and it seems there's a problem reading ticket from the match file. can you pls also email me your match file (preferrably zipped if it's too big), your match settings and the type of lottery you're playing?

The problem is - it uses random, make some , then searches. If it was aloved to use-generate all possible, than its should finish job in some OK time, without memory troubles and with a sure cover and surely properly finished work. An OK time is something like several hours or even more since there is not pen and paper involved, and a computer might finish the work overnight or so . I'm talking here about keno lotteries- (using max overlap 7, 10 numbers combinations out of 80 for example ). It's not easy for them to make some sort of searching, it should be probably easier if started from the very first combination ( that is usually generated with used filtering) when tried to generate all, and then when still using allocated filters also filtering tickets that didn't pass overlap compared to previous already generated ones - which would be actually an additional dynamic match file filter that I described above..And it would work like Ticket Generator - generate all - (use filters if desired) with using a dynamic match file(already generated combinations where number of them starts from 0 and grows) filter

ok, got it. it shouldn't be that hard to implement so i'll stick it to our todo list. although i'm not sure if this will be part of the 4.1 release or if it'll have to wait till 4.1.1

[zz]

[quote=stan]
i see the error log and it seems there's a problem reading ticket from the match file.
[/quote]

I have tried a quite few match files and all of them work absolutely OK if used alone. Some are small - just a few lines and some are bigger. And if used as the match file filter only, all of them work quite OK. But from some reason they do not work if used in the compound filter, combined either among themselves or with any other available filters..:-/

[quote=stan]
ok, got it. it shouldn't be that hard to implement so i'll stick it to our todo list. although i'm not sure if this will be part of the 4.1 release or if it'll have to wait till 4.1.1
[/quote]

Well, that's nice...

[Trust]

good idea but it doesn't fit the compound filter concept too well.
how about introducing a new sub-class of compound filters, called e.g. 'list fiters' where the sub-filters will be listed without and / or conditions and instead there'll be an option to specify 'at least 1 to X filters must pass'?
and of course you'll be able to use 'list filter' as a part of a compound filter and vice versa.

btw, is there a better (one word) english term than 'list filters'?

That would be great-Maybe "Filter Groups" could be a better name?

[Maryland]

I use last 10 drawings match 1 and it doesn't work stan but it you use it seperately and not in the compound filter it works. It won't add to compound filter, just sits there like it's busy but nothing ever happens.

[stan]

[quote=Maryland]
I use last 10 drawings match 1 and it doesn't work stan but it you use it seperately and not in the compound filter it works. It won't add to compound filter, just sits there like it's busy but nothing ever happens.
[/quote]

i uploaded build 426 that should fix this problem.

zz, i'm sorry but i still can't reproduce your error but i'll keep testing.


everybody pls check the 'about' window and make sure you have the latest beta version installed before reporting errors.

[stan]

[quote=Trust]

good idea but it doesn't fit the compound filter concept too well.
how about introducing a new sub-class of compound filters, called e.g. 'list fiters' where the sub-filters will be listed without and / or conditions and instead there'll be an option to specify 'at least 1 to X filters must pass'?
and of course you'll be able to use 'list filter' as a part of a compound filter and vice versa.

btw, is there a better (one word) english term than 'list filters'?

That would be great-Maybe "Filter Groups" could be a better name?
[/quote]

groups, of course!

out of curiosity, can you provide an example what these filter groups can be good for? we'll need to document this feature in application's context help for the public release of version 4.1 and so far i can't think of anything useful...

[Maryland]

Stan the Man you got it this time with the 426 build. And may I add that using the compound filter saves time and seems alot faster when filtering versus the standalone filtering. Thanx!

[zz]

[quote=stan]
zz, i'm sorry but i still can't reproduce your error but i'll keep testing.
[/quote]

Well...the filter was OK if used by itself and btw I just reinstaled all again with the bare package, latest jar file , and including the newer 15.1 java thing. It seems I should have done it earlier because it looks everything will work OK now...:red:...

However, I'm glad you considered that overlap - generate all thingy for your TODO list.
Thanx Stan

[Trust]

out of curiosity, can you provide an example what these filter groups can be good for? we'll need to document this feature in application's context help for the public release of version 4.1 and so far i can't think of anything useful...

Assume the filter group is designed like this:Minimum x to maximum y
of total filters in group(1) We need a box where we assign a number
to the filter(s) Filter A,B, and C belongs to group1 Filter D,E,F and belongs
to group 2 etc.
The usual way to use Filter Groups :the more filters we apply to a package -
even if we set the limits so they "normally" will pass ,one or to filters will fail.
The more filters we apply-the higher is the risk of failing on some of them

If we know that usually we fail on 1 or 2 of in a set of several filters we
can make a group of this filters and set limits according to our experience
with this filter sets.

Using a "Filter group"or several groups we can set that out of total 8 filters in
a group minimum 6 to max 7 of this filters must be correct.
So a "Filter group" can be used as a "insurance" if we apply many filters.

Another strategy is of course to set up many different filters where the
limits are limited to produce small sets of tickets(Sums in a range of 10,
High/low to 3/3, panel to max 2 in row/column etc.and so on)
So we set this filters to belong to the same group and demand that only
1 to max 2 of all filters will hold.

[stan]

thanx for the example Trust.

one more question though - does it make sense to set the maximum number of filters that may pass in a filter group? i mean is it not enough to say that at least X filters must pass?

when i have a group of e.g. 5 filters and all of them pass then everything is ok, however i do want to specify that at least 2 filters must pass.

i can't think of a situation where it would be wrong that all my filter passed according to my filter parameters...

or am i wrong?

[Trust]

Usually nothing wrong in that all filters pass of course
But that depends on how we set the limits in each individual
filter.
To limit the max number of filters in a group to less than all filters
should generate fewer tickets.
So if we use many filters in a group or use "narrow"limits in individual filters it becomes unlikely that all filters pass.
And if i am convinced that not all of my filters will make it-so limiting
max filters in this group will produce fewer tickets than a max setting of all
filters to pass?

[Maryland]

Stan, I removed java from my computer then upgraded like you said. I opened the beta version fine then after one time it won't open anymore. My original version is still file as far as loading. Any help?

[Maryland]

Ok Stan found the problem. If you change preferences look and feel to CDE/Motif then either the original or the beta version will not open if changed in either. Also I noticed you don't have the show windows in preferences in the Beta version. I had to backtrack what I did to find the problem so it wasn't updating Java.