Pro parentheses boolean interface (topic reviving)

[Leopoldus]

So, AND precedes OR by default (and there's no way to overwrite the default because I do not want to introduce parentheses - it would just be too much).

Let me come back to this discussion, using a practical problem I've run into.
Suppose you have relations with some company, and your memory is good enough to remember nearly this company's name, it is "Jonson and brothers Ltd", or "Johnsonn and sones LLC", or surely something like this. Now you indeed need to find the letter you have written them concerning ordered software. If you would have the option to use boolean alternative and parentheses, it is not so big problem to find what you need by the following query:
(jonson | johnson | johnsonn | jonnson) & (sons | brothers | sisters) & (LLC | LTD | Inc) & (letter | response | reply | answer) & (soft | code | program)
Not very simple, however is real.
But as you have NO parentheses interface in TrackerV3, so the query you have to compose is something like this:
jonson & sons & LLC & letter & soft | johnson & sons & LLC & letter & soft | jonson & sisters & LTD & reply & code | ..........................................................................................................
Well, you see, what I mean. The number of possible combinations is very big (factorial(4x3xx3x4x3) ?? I've forgotten my school mathematics) - or even more then very big.

If you think parentheses interface is too complex for users (I don't think so, but you might), please consider, that parentheses using is only option, not an obligation: those users who prefer interface simplicity to program's functionality, must not use them in their queries at all, and in their queries logicdl AND will be always stronger then logical OR.

[admin]

Ok, I see your point.

Question to RegExp experts: can't that be done via RegExp???

Donald

[admin]

I have a cool idea! Forget parentheses, what do you think of this:

Operator precedence: ! > & > | > AND > OR

That would make a lot of boolean nesting possible, while not interfering with regular user habits (normally you don't mix symbol types but use either the &-| set or the and-or set).

Your example would be:
jonson | johnson | johnsonn | jonnson AND sons | brothers | sisters AND .... etc.

Cool?
Donald

[Leopoldus]

Hm... Yes, it should work and does solve my problem. But...
Do you really think that this mixed precedence is more cleare and intuitive then parentheses interface??? I doubt very much...

[admin]

Do you really think that this mixed precedence is more cleare and intuitive then parentheses interface??? I doubt very much...

Right, parentheses would be the best solution for the user. The usage is self-evident, no explanation necessary.

I still hesitate because the moment I give you parentheses you will ask for more levels of nesting! So where do we stop?
What about my competitors? Do you know of other file finders that use Bool plus parentheses? How many levels of parentheses nesting do they allow? 1, 2, 3, infinite?

[Leopoldus]

I give you parentheses you will ask for more levels of nesting!

Well, I think one level is a bit too little, two levels should meet usual needs with not very complex expressions, three levels will be enough for any case in the world.
I can't imagine an occasion when somebody needs more, and nobody can think clearly enough to compose such expression.

[admin]

I can't imagine an occasion when somebody needs more, and nobody can think clearly enough to compose such expression.

You never know... anyway, since nothing but the best is good enough for TrackerV3, I'm actually planning infinite nesting levels! I'm just breeding over an ultra-cool algorithm... it's a five diamond piece of code I tell you!

[Leopoldus]

it's a five diamond piece of code I tell you!

I do know it, because your TrackerV3 is in general worth this value!

P.S.
What about searching process speed? Can you imagine how much time need searching by query with 5-6 nesting levels of logics?

[admin]

Yo, here it is! Boolean search now supports parentheses of up to 256 nesting levels! See new BETA...

What about searching process speed? Can you imagine how much time need searching by query with 5-6 nesting levels of logics?

Check it out, I don't think you will find any significant slowing down due to level depth. More important is the number of necessary comparisons to decide whether or not a file is a match. You have a certain influence by chosing the order of parts in your search term, which is processed from left to right. Say, if you have a lot of "*.txt" files and look for John or Mike *.txt-files, you have two possibilities:
1. (John | Mike) & *.txt
2. *.txt & (John | Mike)
The first will be faster, since for most files only the first test, (John | Mike), is necessary to decide that they are not a hit.

[Leopoldus]

Greate!
TrackerV rules forever!! Indeed!