bulk filtering

[stan]

there are many feature requests for new filters that are either a combination of existing filters and/or their extensions. i was thinking about defining some sort of 'filter language' that would allow you creating such filters in a form of a text file. usually it takes me more time to code user interface for a new filter than the actual ticket-checking code.
so you would create a text file like this:

[m]leave sum range: 120-200
and
remove odd/even: 1:5
and
remove odd/even: 5:1
and
leave wnh col0 sum range: 300-320
or
leave wnh col1 sum range: 521-549[/m]

load this file into expert lotto and filter the package according to it. so in fact you'd be editing/saving/loading compound filter definitions.
do you think it would be worth implementing such a filter language and compiler or is it a bad idea?

(and if you think it is worth it, please state why. comments like 'great idea, let's try it' are no justifications for me to actually spend a lot of time at my computer implementing it:)

[Sledge]

Whats the difference between this and the compound or groups filtering options ?

Just trying to get an understanding of why you want to do this.

[stan]

[quote=Sledge]
Whats the difference between this and the compound or groups filtering options ?
[/quote]
the difference is that it should be easier to edit a text file than going through the filter hierarchy in expert lotto user interface. you'll also be able to enter many more combinations of filter parameters (e.g. thousands of segment combinations) than it is practical to do so in application's ui

[CSenior]

Stan~ I think that is a great idea! I would take loading a text file with commands any day over a UI. You would have to compile a cheat sheet of all the available commands and show plenty of examples for all. Any addition or improvement brings us one step closer to the jackpot.

Thanks!

[Bobijohn]

Stan

You have specifically asked for our comments so I have given it considerable thought and offer the following.

1) What you are suggesting would certainly be a “cutting edgeâ€￾ enhancement. However, I don’t believe that it will give you much relief in terms of dealing with additional filter requests. In fact, it may open up a whole lot more questions and requests for additional features just on its own.
2) Would it not take you a considerable amount of time and effort to create? If so, I suspect you may be better off dealing with the additional filter requests as you currently do.
3) I note that you have about 200 members on your forum. About 20 are active and make great contributions. These members are also pretty computer savvy and would probably make great use of what you suggest. It would take being reasonably savvy to do so. What about the other 180 members? They are still going to have requests that you will need to deal with.
4) Assuming you decided to proceed along this path whatever you develop will need to be easy to understand and use. Good help files would be a necessity, specifically regarding allowable syntax, with lots of examples.
5) In summary, this is not to discourage you from developing such an enhancement. It could be very valuable, but to a minority of users. I suspect your time, at present anyway, would be better applied to dealing with the numerous outstanding issues outlined in the forum.

These are just my thoughts. I am sure others may agree or disagree. That is what the forum is all about. And, with your diligent management this forum, continues to be a source of excellent ideas. Expert Lotto is by far the best lottery analysis program available.

Bobijohn

[Jerzy]

Stan,

I am interested in your idea of bulk filtering. If we are able to enter many more combinations of filter parameters than it is practical to do so in application's UI, it would be a remarkable enhancement, very useful, particularly to those members who are conducting experiments and who are researching into ways of effective playing. Better approaches to filtering and better strategies could be discovered.

It would save our time if we are able to use more filters more effectively in a shorter time.

Jerzy

[stan]

well, the compound filters are already stored in a text file (xml file actually) and if you know what you're doing (which most of you probably don't:). so i was thinking of reusing and simplifying that format somehow.
it really might require considerable amount of time to implement so i'm still not sure i'll go ahead with this but go through the source code and see what it would take to implement it...

[Falcon]

Stan,

I have no objection to going down the text file path but this to me can only be for those who have the skills to put together a number filters as a compound group. Many if not most of us as you suggest yourself simply will not have the skills to do this. Thus for those not so skilled I believe a filter ought to be available in the first instance as a source code product and that this approach be the EL standardised way of doing things.

Thus for Bobijohn's suggestion of a filter to use OOEEOEEOE... type parameters I would see the filter with a spinner button to go back the number of desired draws as more simple and straight forward than copying the last 50 or so occurrences of OOEE... etc into a text file.

falcon

[stan]

as there's no overwhelming support for this feature i won't try implementing it:)
i'll continue adding new filters with proper user interface with only some exceptions where too many input parameters are required. those who are really keen in exploring text file input for their filtering process may study the format of existing compound filters. it shouldn't be that hard to generate it from your excel sheets:)

[stan]

oh, and thank you very much for your comments!

[Falcon]

Well, disappointed of course to find lack of over whelming support for this unique filter that Bobijohn has proposed. I must admit I am a fan of the more traditional type of filtering available with EL and have not yet found the need to move into the apparently popular Segment filtering processes, thus I like the concept of these generic type filters where quite large numbers of tickets can be removed with relative safety. This OOEEO.... type filter would add nicely to that filter armoury.

However if such a filter can be accommodated within a bulk text file approach I shall be happy.

r

falcon