BUG!! Are the logical operators working?

If I connect two terms with an "OR" (or comma) I expect to see a number of results somewhat similar to the sum of the two terms individually ie.somewhere between the difference between the two individual terms (assuming complete overlap) and the sum of the two individual terms (assuming no overlap). I am getting results that make no sense so I assume I am missing something.

Example from Everything Search/OR

Example all resources/OR

Example all resources/comma

Find more posts tagged with

Comments

PetahChristian

Thanks, MJ, for catching bugs like this. It's disturbing to see that the program can produce inconsistent results, depending on the search.

Does Faithlife use any type of (regression) unit testing, to ensure that (past) errors aren't introduced into the search results?

Mark Barnes

The problem isn't that OR isn't working. The problem is that (Jericho Road) is ambiguous, and Logos is interpreting it differently in different contexts (which it shouldn't of course). But what you really mean is "Jericho Road", which behaves as you would expect. If OR (Jericho Road) was interpreted correctly, it would translate to OR (Jericho AND Road), which also behaves correctly, but doesn't give you the results I think you'd expect.

PetahChristian

https://community.logos.com/discussion/comment/862220#Comment_862220

The problem isn't that OR isn't working. The problem is that (Jericho Road) is ambiguous, and Logos is interpreting it differently in different contexts (which it shouldn't of course). But what you really mean is "Jericho Road", which behaves as you would expect. If OR (Jericho Road) was interpreted correctly, it would translate to OR (Jericho AND Road), which also behaves correctly, but doesn't give you the results I think you'd expect.

Not to beat a dead horse, but if Mark has to explain these nuances and how Logos really interprets it, how can someone without an advanced education in Logos searching expect to get the results they expect?

While I grasp the basics of AND, OR, and literal phrases in quotes, that (Jericho Road) might mean (Jericho AND Road) is obscure.

Will we ever get to a point where we won't need to know or use esoteric syntax?

Mark Barnes

https://community.logos.com/discussion/comment/862221#Comment_862221

While I grasp the basics of AND, OR, and literal phrases in quotes, that (Jericho Road) might mean (Jericho AND Road) is obscure.

Parentheses are normally used to determine the order of priority for boolean operators. So (Jericho Road) is identical to Jericho Road in a normal search. And, just like Google, Logos assumes that if you don't specify an operator, you mean AND.

So (Jericho Road) and Jericho Road and Jericho AND Road are all identical.

The parentheses make a difference when combine with OR, in just the same way that the make a difference in math.

Just as 3 + 4 x 5 is different to (3 + 4) x 5, so A OR B AND C is different to (A OR AND C

None of this is esoteric, it's all completely standard. It's confusing because (a) MJ's syntax was valid, but unnecessarily esoteric, and (b) Logos misinterpreted that esoteric syntax, which is a bug because it was valid.

PetahChristian

https://community.logos.com/discussion/comment/862225#Comment_862225

Just as 3 + 4 x 5 is different to (3 + 4) x 5, so A OR B AND C is different to (A OR AND C

Ah, I understood precedence and order of evaluation from math and programming, but hadn't made the leap that Logos was using the same logic.

Thanks for filling in the missing progression regarding the implied AND. I can see now how the syntax is standard.

Perhaps one day, there will be a Courses tool resource that expands on the search cookbook, since some of these nuances are not obvious, unless explained in more than one line.

MJ. Smith

https://community.logos.com/discussion/comment/862220#Comment_862220

But what you really mean is "Jericho Road", which behaves as you would expect.

I actually meant Jericho AND Road as I wanted to pick up things such as Jericho Road, on the road to Jericho ... I put the parens in for clarity assuming they would have absolutely no effect. I had thought the problem with lists and logical operators was fixed. Was I wrong or is this a new bug?

Andrew Batishko

https://community.logos.com/discussion/comment/862302#Comment_862302

Currently it isn't valid syntax to specify multiple terms without an operator inside parenthesis. Invalid searches are not likely to return the results you are looking.

We do have an open case to add support for inserting an implicit AND operator in this situation (as is done when you run the query without parenthesis).

This is not the same problem as lists. A list in a query is distinguished by use of the comma operator.

MJ. Smith

https://community.logos.com/discussion/comment/862307#Comment_862307

A list in a query is distinguished by use of the comma operator.

My misunderstanding. I thought a space also indicated a list. I believe that the wiki may need changed.

But that doesn't explain how screwed up this search is. Here is a clearer example as it focuses more specifically on the problem and to my mind should provide identical results rather than 3 separate opinions:

MJ. Smith

https://community.logos.com/discussion/comment/862307#Comment_862307

Currently it isn't valid syntax to specify multiple terms without an operator inside parenthesis.

This is the sort of esoterica that justifiably gives the Logos search a bad name and thoroughly annoys me. Why?

because it's validity is implied by the simple ability to build complex searches by the replacement of a complex item for a simple one ==> i.e. basic logic, railroad diagrams, etc.
because Logos gives no indication that the syntax is faulty ==> the free text editor CONTEXT does a better job at editing syntax from a set of basic user rules
because there is no tool to identify what Logos has actually done to allow one to identify and correct the error -- not even a simple compare results if they can't be exported to a passage list
because this is the second undocumented limitation I have run into during the past week (the other being the Search field limitation)

I have a basic rule - if I don't know what the search I wrote asks for, then I don't trust the results ... and I don't trust Logos/Verbum searches and haven't for several years.

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/862312#Comment_862312

When the Logos query parser was first designed in Logos 4, it had a primary design goal: just like Google, there are no invalid queries. We didn't want people to have to learn complicated Boolean queries and syntax. We wanted them to be able to paste in a sentence they copied from a book and it would "just work" (even if that sentence contained colons or commas or the words "and" or "before", etc.). So the query parser tries to do the best it can with what you entered, in many cases just ignoring all the punctuation and falling back to the words you typed.

However, since then we have added dozens of new data sets, search extensions, more data types, more operators, and more syntax. We've now reached the point where you want to be told "INVALID QUERY. USER ERROR. TRY AGAIN." (but maybe in a slightly more friendly way). We have an open case in our bug tracker to try to infer when it seems likely that the user is trying to enter a complex query but didn't quite get it right and then either: a) auto-correct, b) suggest corrections, or c) fail early and not run a query that the user probably didn't want.

But until that's implemented, you'll need to be an expert on search syntax and/or come to the forums for help when you're trying to build a complex query and are not sure if you've gotten the operators exactly right.

Andrew Batishko

https://community.logos.com/discussion/comment/862309#Comment_862309

A list in a query is distinguished by use of the comma operator.

My misunderstanding. I thought a space also indicated a list. I believe that the wiki may need changed.

But that doesn't explain how screwed up this search is. Here is a clearer example as it focuses more specifically on the problem and to my mind should provide identical results rather than 3 separate opinions:

Query 1 is exactly the same as <Topic Road System in Palestine> AND Jericho AND Road I don't believe this is a valid query. Therefore the comma is ignored and you get three terms AND'd together (thanks to the implicit AND between two terms without an operator).

Query 2 is exactly the same as (<Topic Road System in Palestine>, Jericho) AND Road Since there is no comma between Jericho and Road, then Road (which is its own separate term) does not get included in the list and receives an implicit AND. I think this may also be an invalid query. I'm not entirely sure what the equivalent it.

Query 3 is exactly the same as <Topic Road System in Palestine> OR (Jericho AND Road) Due apparently to the order of operator precedence.

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/862309#Comment_862309

Here is a clearer example as it focuses more specifically on the problem and to my mind should provide identical results rather than 3 separate opinions:

Invalid query. Boolean operators cannot appear in a list. Try using OR.
Invalid query. You need an operator between the list (first two terms) and the final term.
Valid query but you should probably indicate desired precedence with parentheses.

MJ. Smith

https://community.logos.com/discussion/comment/862319#Comment_862319

Invalid query. Boolean operators cannot appear in a list. Try using OR.

Okay, this is the restriction that I thought had been lifted. My mistake.

Invalid query. You need an operator between the list (first two terms) and the final term.

I erroneously believed that AND was implied and did not need to be specified. The context in which it is implied is obviously narrower than I realized.

Valid query but you should probably indicate desired precedence with parentheses.

Yes, I had had the parens and would usually use them but previous posts had suggested they might be part of the problem.

PetahChristian

https://community.logos.com/discussion/comment/862316#Comment_862316

We have an open case in our bug tracker to try to infer when it seems likely that the user is trying to enter a complex query but didn't quite get it right and then either: a) auto-correct, b) suggest corrections, or c) fail early and not run a query that the user probably didn't want.

a) Please don't autocorrect, because it may either guess wrong and run something we didn't mean, or run something we don't actually understand due to a lack of skill on our part, putting us back in the same scenario where we are now/today.

b) Please do suggest corrections, accompanied by (optional) explanations, so we can ensure what the search will do is actually what we intended. While I don't want power users to be deprived of their syntax, it would be nice if search provided some sort of "Bible Browser" interface which could interactively (construct the search syntax and) perform complex searches. People could then learn from it, and move from the interactive to power searches, when they know what they're doing, and can construct queries faster on their own.

c) Please don't simply fail early and do nothing, because it's effectively "INVALID QUERY. USER ERROR. TRY AGAIN" which no one wants to be told, regardless of how friendly you make it.

PetahChristian

https://community.logos.com/discussion/comment/862327#Comment_862327

Invalid query. Boolean operators cannot appear in a list. Try using OR.

Okay, this is the restriction that I thought had been lifted. My mistake.

Invalid query. You need an operator between the list (first two terms) and the final term.

I erroneously believed that AND was implied and did not need to be specified. The context in which it is implied is obviously narrower than I realized.

Valid query but you should probably indicate desired precedence with parentheses.

Yes, I had had the parens and would usually use them but previous posts had suggested they might be part of the problem.

If really intelligent people have to keep track of things like this that can trip them up, perhaps we should transition from a system that requires users to master a set of syntax and parser rules which continue to change from one version to another, to ensure that they can confidently get accurate results.

Why should pastors and bible students be required to learn about whether an operator is or isn't needed, implicitly supplied, or extraneous, or need to understand boolean logic and operator precedence?

MJ. Smith

https://community.logos.com/discussion/comment/862316#Comment_862316

We have an open case in our bug tracker to try to infer when it seems likely that the user is trying to enter a complex query but didn't quite get it right and then either: a) auto-correct, b) suggest corrections, or c) fail early and not run a query that the user probably didn't want.

It seems to me that the first step is to standardize as all logic systems and other search systems have: If expression1 is a valid Search and expression2 is a valid Search then expression1-operator-expression2 is a valid Search i.e. a guaranteed recursive structure.

The second step is to turn an expression red as soon as you can tell it is invalid e.g. when search fields are set, as soon as a Search extension can be recognized "{" turn it red as invalid.