Bug: Comma vs. OR in search syntax

https://community.logos.com/discussion/comment/130034#Comment_130034

Whisper mode back on....

Richard, even if it was spelled right, the OR doesn't work in this situation

Whisper mode off...

https://community.logos.com/discussion/comment/130051#Comment_130051

I'm also pretty sure that the parentheses aren't necessary in this instance.

https://community.logos.com/discussion/comment/130034#Comment_130034

Could that be the issue?

No, spelled right it still fails. The OR would have given some result anyway.

https://community.logos.com/discussion/comment/130052#Comment_130052

I'm also pretty sure that the parentheses aren't necessary in this instance.

Even if they are not necessary, they should not matter. Using the coma without parens gives the same result.

But using OR without the parens gives a very different result. So with the actual operator the parens make a difference, but with the short form of the operator, a comma, the parens do make a difference.

BTW the search options are the same on all searches (word forms, etc.).

https://community.logos.com/discussion/comment/130058#Comment_130058

But using OR without the parens gives a very different result. So with the actual operator the parens make a difference, but with the short form of the operator, a comma, the parens do make a difference.

In fact it the same results as if I did this search with the parens around the last part of the expression.

If I remember right this means that the Logos parsing of searches is using Reverse Polish notation.

https://community.logos.com/discussion/comment/130052#Comment_130052

I'm also pretty sure that the parentheses aren't necessary in this instance.

You are likely right. However, any self-respecting logician would add them so Logos should accept them to distinguish between:

(lift NEAR hands) OR (raise NEAR hands) - INTENDED

(lift, raise) NEAR hands - should give the same results as above

lift OR (raise NEAR hands) - NOT INTENDED should yield different results

1 and 2 should yield the same results; 3 should yield more results. But

One and two should be the sum of the following two searches:

also equal in theory

To summarize my results: 505 = 502 = 855+317 = 60+317 < 855 Unfortunately my math education stopped after calculus.

This is clearly a logic bug (or 2 or 3) - who is the resident Logos logician?

[:$] I edited this to correct a stupid error.

Bradley Grainger (Logos)

Is there some "logical" explanation for this behavior? If not it needs to go in the "bug" wiki so we know that is known.

The "logical" explanation is that comma and OR are two different operators with different precedences, which leads to results you don't expect. However, it's completely reasonable that it should work exactly as you expect; as mentioned in the post you linked to, we have cases open in our bug database to standardise this behaviour.

https://community.logos.com/discussion/comment/130098#Comment_130098

comma and OR are two different operators with different precedences

Ah! So there is a difference! [:O] I think I was told at a Camp Logos session that they were the same. I have also checked the wiki http://wiki.logos.com/Search_HELP and find no documentation there for the comma operator.

Please could we get a complete list of the search operators with all the details. And how about a some examples of complex searches using several levels of nesting. (I assume the search engine is recursive.) Inquiring minds want to know. [:)]

we have cases open in our bug database to standardize this behavior.

Good! Yet not only standardized between Basic, Bible, and Syntax searches, which is what I took the other post to mean, but also consistent when we use equivalent expressions.

https://community.logos.com/discussion/comment/130098#Comment_130098

The "logical" explanation is that comma and OR are two different operators with different precedences, which leads to results you don't expect.

But that doesn't explain why hands NEAR raise gives different results than raise NEAR hands. Surely NEAR is not direction dependent.[:^)]

Bradley Grainger (Logos)

https://community.logos.com/discussion/comment/130139#Comment_130139

But that doesn't explain why hands NEAR raise gives different results than raise NEAR hands. Surely NEAR is not direction dependent.

"hands NEAR raise" and "raise NEAR hands" both show 317 results in 151 verses in 5 resources in your screenshots.

The screenshot for "lift NEAR hands" looks like it's really just the results of a search for "lift". Can you reproduce this? (I can't.) Is it possible you entered the new query ("lift NEAR hands") but didn't execute it?

https://community.logos.com/discussion/comment/130139#Comment_130139

But that doesn't explain why hands NEAR raise gives different results than raise NEAR hands. Surely NEAR is not direction dependent.

Martha,

I just tried "raise NEAR hands" and "hands NEAR raise" and both results were identical.

https://community.logos.com/discussion/comment/130143#Comment_130143

I just tried "raise NEAR hands" and "hands NEAR raise" and both results were identical.

Yes, I must have screwed up - or got caught in a time warp today. My apologies.

https://community.logos.com/discussion/comment/130126#Comment_130126

I have also checked the wiki http://wiki.logos.com/Search_HELP and find no documentation there for the comma operator.

It appears under the heading of 6. Lists but I've added explicitly to 2. (Boolean).

Please could we get a complete list of the search operators with all the details. And how about a some examples of complex searches using several levels of nesting. (I assume the search engine is recursive.) Inquiring minds want to know.

I think all operators are documented (do you want to know about + for AND --- it's too near my bedtime!?).

https://community.logos.com/discussion/comment/130373#Comment_130373

it's too near my bedtime

Sorry to keep you up late. [:)]

I must have been sleepy [|-)] when I looked at the wiki. Thanks for the additions.

Bradley Grainger: The "logical" explanation is that comma and OR are two different operators with different precedences, which leads to results you don't expect.

Based on what Bradley said above, comma and OR are not the same. I wonder what the difference is. He did indicate it had to do with precedence, which might explain why nesting the operations gave different results. Maybe Bradley will give us the order of precedence (order of operations) or point us to a resource. We need it.

Hopefully I am not the only one doing searches with nested operations!

https://community.logos.com/discussion/comment/130390#Comment_130390

Here is some more data on the comma vs OR thing.

Search using the comma.

It seems to treat the search as you'd expect; where does the word little or children appear near the word writing?

In this next case using the OR operator, it searches for "little" as a unit, and then separately "children NEAR writing" as a separate unit.

And when you put the search terms in parentheses using a comma, it doesn't seem to change things...It treats it like the first search.

When you do the same with the OR operator...(little OR children) NEAR writing.....YOU GET NOTHING...

When you put both search terms in their own parentheses separately, we get them treated like an OR (either of the two terms near the third search term)

https://community.logos.com/discussion/comment/130445#Comment_130445

Generally logical expression are evaluated from right to left just like complex expression in math. (In fact this kind of search logic is a branch of mathematics.) That may shed some light on what you got.

Comments on each example

1. little, children NEAR writing - I think I agree with your evaluation

2.little OR children NEAR writing = little OR (children NEAR writing). The expression (children NEAR writing) is evaluated first. The results are ORed with "little." This appears to be what you got.

3. (little, children) NEAR writing = ((little, children) NEAR writing). The inner expression (little, children) is evaluated first. The results are "NEARed" with writing.

4. (little OR children) NEAR writing - I would think would be the same as #3. However we have been told that it is different and will have to wait for development to tell us about it.

5. (little) (children) NEAR writing - Is not normally written this way. You need at least one operator inside side each expression. So the system probably dropped the parens and got "little children NEAR writing." I guess that, based on the space, it did "(little children) NEAR writing. Which accidentally gives you the same results as "little, children NEAR writing" because there are no examples in the resource that do not match both formulas.

It would appear then, and this is purely a guess which may be 100% wrong, that comma, and space operators have a high precedence then when you spell out the operators. Again this is just a quick guess. And this may be one of the "consistency" problems Bradley is talking about.

https://community.logos.com/discussion/comment/130480#Comment_130480

5. (little) (children) NEAR writing - Is not normally written this way. You need at least one operator inside side each expression.

As this is a mal-formed request, I'd prefer to see it rejected by Logos. Anyone else old enough to remember the old logic game WFF 'n Proof?[;)]

edited to correct name of game

https://community.logos.com/discussion/comment/130482#Comment_130482

this is a mal-formed request

I was trying to be compassionate. [:)] Robert worked hard to get all these and post them.

I'd prefer to see it rejected by Logos

[Y] And soon all Logos users will be WIF'n Proof wizards.

https://community.logos.com/discussion/comment/130494#Comment_130494

But Robert had a vertical bar | (which means the same as OR) in example #5, so it's not malformed.

https://community.logos.com/discussion/comment/130503#Comment_130503

But Robert had a vertical bar | (which means the same as OR) in example #5, so it's not malformed.

I took that to be his cursor. It appears in different places in his examples.

The wiki article http://wiki.logos.com/Search_HELP does not list the vertical bar as an operator. I wish it were an operator, it matches the standard that I have used for years.

https://community.logos.com/discussion/comment/130511#Comment_130511

Though WFF 'n proof came out in 1961, the company is still around and making games...and W 'n P is still available!

http://wffnproof.com/

https://community.logos.com/discussion/comment/130390#Comment_130390

Based on what Bradley said above, comma and OR are not the same. I wonder what the difference is. He did indicate it had to do with precedence, which might explain why nesting the operations gave different results.

Here's some empirical results and guidelines.

1. Get Zero results when you know better

lord NEAR (Jesus AND Christ) - gives 0 results --> avoid mixing boolean and non-boolean operators [NEAR]

lord AND (Jesus AND Christ) - OK

lord AND (Jesus Christ) - treats AND as a word --> avoid mixing boolean and non-boolean operators [the space for AND]

Alternatives: lord Jesus Christ; "lord Jesus Christ"; lord NEAR Jesus NEAR Christ --> Keep it simple

2. Results may look OK

lord NEAR (spirit OR God) - treats NEAR as a word --> avoid mixing boolean and non-boolean operators

lord NEAR (spirit AND god) - treats NEAR as a word --> avoid mixing boolean and non-boolean
operators

(lord Jesus) OR Christ - treats OR as a word --> avoid mixing boolean and non-boolean
operators [the space for AND]

3. Exceptions (where mixing works)

(lord NEAR Jesus) OR (lord NEAR Christ) is equivalent to lord NEAR (Jesus, Christ) but results are different because of the way "lord" is counted!

4. Precedence

parentheses (..) override operator precedence e.g. lord AND (spirit OR God) is not lord AND spirit OR God = (lord AND spirit) OR God

logical AND + Proximity operators >> logical OR e.g. lord BEFORE Jesus OR god NEAR Christ = (lord BEFORE Jesus) OR (god NEAR Christ)

5. Guidelines

Avoid mixing boolean and non-boolean
operators [NEAR, BEFORE, space, comma etc.].

Use Lists [comma separated terms instead of OR] with non-boolean
operators.

Avoid using space for AND in mixed expressions

https://community.logos.com/discussion/comment/130511#Comment_130511

The wiki article http://wiki.logos.com/Search_HELP does not list the vertical bar as an operator.

Take your pick of symbols that work as AND in simple cases:-

| + & > <

eg. lord | Jesus; lord + Jesus

NB. lord|Jesus|christ = "lord jesus christ"

For obvious reasons these will not be documented in the wiki.

https://community.logos.com/discussion/comment/130648#Comment_130648

lord NEAR (Jesus AND Christ) - gives 0 results --> avoid mixing boolean and non-boolean operators [NEAR]

Avoid mixing boolean and non-boolean operators [NEAR, BEFORE, space, comma etc.].

Dave,

I know that this is going to make me sound stupid but I'll ask...could you please explain more fully? Why do you not mix "AND" "OR" "NEAR" or "BEFORE"?

I'm not following...

https://community.logos.com/discussion/comment/130703#Comment_130703

A search for lord NEAR (Jesus AND Christ) is illogical syntax. If you think about it, Jesus AND Christ means that the words Jesus
and Christ both appear in the same article. There's what position
is the results of that search? The position of Jesus? The position of
Christ? The middle of the two? You can't really then do a proximity
search with the results of that.

What you probably really mean is one of the following:

(lord NEAR Jesus) AND (lord NEAR Christ)
(lord NEAR Jesus) AND (lord NEAR Christ) AND (Jesus NEAR Christ)

(Those are three different queries, that - in theory - provide three different search results. You'd need to run the search on your entire library to see the difference. Look at the article count when you do so. I get article counts of 41,826 and 40,624 in my library.)

Imagine the following articles (… represents a long gap):

"Lord Jesus Christ" - this would match both.
"Lord Jesus … the Lord the Christ" - this would match (1), but not (2) because Lord is not near to Christ.

https://community.logos.com/discussion/comment/130707#Comment_130707

I should add that I disagree with Dave slightly. The rule is not "Avoid mixing boolean and non-boolean operators". The rule is that you shouldn't use do a proximity search with a result that doesn't return a position. So

(Lord OR Jesus) NEAR Christ doesn't work, because Logos does this logically. It first does (Lord OR Jesus), but as this search doesn't return position information, it can't carry on.
(Lord, Jesus) NEAR Christ does work, because Logos internally translates this into (lord NEAR Christ) OR (Jesus NEAR Christ)

So this is not a bug as such. It's just that what is logical in our minds isn't necessarily logical mathematically.

https://community.logos.com/discussion/comment/130710#Comment_130710

Mark,

thank you for the thorough explanation...I'll ruminate on that for a while.

https://community.logos.com/discussion/comment/130713#Comment_130713

So..Mark,

It's the positional thing that messes things up.

Then these would be valid searches:

(Jesus BEFORE Christ) NEAR whom

(Jesus BEFORE Christ) WITHIN 10 words whom

right?

https://community.logos.com/discussion/comment/130710#Comment_130710

The rule is not "Avoid mixing boolean and non-boolean operators". The rule is that you shouldn't use do a proximity search with a result that doesn't return a position.

Mark, your feedback is welcome as I wasn't entirely satisfied with the "Avoid..." guideline. I'm wanting something that is relatively self-explanatory for the wiki.

https://community.logos.com/discussion/comment/130722#Comment_130722

Clearly, I'm going to purchase the WFF 'n Proof game soon.... [:$]

https://community.logos.com/discussion/comment/130721#Comment_130721

Then these would be valid searches:

(Jesus BEFORE Christ) NEAR whom

OR

(Jesus BEFORE Christ) WITHIN 10 words whom

Yes! Doing the search (Jesus BEFORE Christ) WITHIN 1 WORDS whom in the ESV really clearly shows how that syntax is interpreted.

https://community.logos.com/discussion/comment/130722#Comment_130722

Mark, your feedback is welcome as I wasn't entirely satisfied with the "Avoid..." guideline. I'm wanting something that is relatively self-explanatory for the wiki.

Somewhere there's a post from Bradley a couple of months ago that talks (I thought) about OR searches returning a binary result which is why the can't be used in this context. But I can't find the post. I'm pretty sure you were part of the discussion though. Do you remember?

https://community.logos.com/discussion/comment/130727#Comment_130727

Mark,

Hey! You're right...it really illustrates that idea well...thanks very much.

https://community.logos.com/discussion/comment/130721#Comment_130721

Then these would be valid searches:

(Jesus BEFORE Christ) NEAR whom

OR

(Jesus BEFORE Christ) WITHIN 10 words whom

Now we are getting deep. They work but I can demonstrate a problem with (Christ BEFORE Jesus) NEAR whom:-

ESV: 7 in 3 verses. Expected 9 in 3 (similar in NASB95)

If proximity was an issue only Acts 2:36 should be returned. Why return two results in each of the other 2 verses?

(Christ BEFORE Jesus) WITHIN 9 words whom returns the same results so we know that NEAR is 9 words! To obtain the expected result I have to use (Christ BEFORE Jesus) WITHIN 13 words whom but still get anomalous results with other separations. I'll register this as a bug.

https://community.logos.com/discussion/comment/130737#Comment_130737

Dave,

As I said to Robert the search (Jesus BEFORE Christ) WITHIN 1 WORDS whom shows exactly how these strings are interpreted. It's hard to put into words, but it's something like this: Search for verses where Jesus appears before
Christ and one of those words is NEAR to 'whom'

If you run the search and you'll 'see' it.

So (Jesus NEAR whom) BEFORE Christ searches for occasions where Jesus is near to whom, and one of those words is BEFORE Christ.

If you want a search string that only returns Acts 2:36 you would be searching for occasions where Jesus is near to whom and both of those words are BEFORE Christ. I don't think that's possible.

I'm not sure that's a bug, or even unexpected behaviour, but it does illustrate the complexity of linking searches with a proximity operator, and of the inadequacy of Logos' documentation.

https://community.logos.com/discussion/comment/130728#Comment_130728

Somewhere there's a post from Bradley a couple of months ago that talks (I thought) about OR searches returning a binary result which is why the can't be used in this context. But I can't find the post. I'm pretty sure you were part of the discussion though. Do you remember?

Yes! But I struggled to express that "simply". I'll have another go tomorrow.

https://community.logos.com/discussion/comment/130746#Comment_130746

If you run the search and you'll 'see' it.

So (Jesus NEAR whom) BEFORE Christ searches for occasions where Jesus is near to whom, and one of those words is BEFORE Christ.

Obviously, I ran Robert's search (Jesus BEFORE Christ) NEAR whom. It illustrates both words satisfying the NEAR constraint. (Christ BEFORE Jesus) NEAR whom did not.

https://community.logos.com/discussion/comment/130758#Comment_130758

Mark ANDEQUALS verysmart

Dave ANDEQUALS verysmart

Robert ANDEQUALS thankful.

[;)]

https://community.logos.com/discussion/comment/130758#Comment_130758

If you run the search and you'll 'see' it.

So (Jesus NEAR whom) BEFORE Christ searches for occasions where Jesus is near to whom, and one of those words is BEFORE Christ.

Obviously, I ran Robert's search (Jesus BEFORE Christ) NEAR whom. It illustrates both words satisfying the NEAR constraint. (Christ BEFORE Jesus) NEAR whom did not.

Sorry for not being clear. I was talking about the search (Jesus BEFORE Christ) WITHIN 1 WORDS whom which is the same as Robert's but by restricting to a one-word nearness, it makes it much clearer why there's a match.

https://community.logos.com/discussion/comment/130650#Comment_130650

For obvious reasons these will not be documented in the wiki

And certainly they should not be listed. I mentioned that it was not there as proof that it was not a valid operator, but rather what we saw was a random cursor placement.

Again it would be good if the search engine would flag invalid operators as errors. In other words the search engine parser should enforce valid syntax and operators. Will that give lesser trained users some frustration? Yes. However, I think most would rather have an error message then unknowingly get invalid results.

https://community.logos.com/discussion/comment/130768#Comment_130768

In other words the search engine parser should enforce valid syntax and operators.

I agree. It could also suggest alternatives for one click, which would help train users.

For example, if you searched for (Jesus OR Christ) NEAR love, it could suggest (Jesus NEAR love) OR (Christ NEAR love)

https://community.logos.com/discussion/comment/130771#Comment_130771

I agree. It could also suggest alternatives for one click, which would help train users.

For example, if you searched for (Jesus OR Christ) NEAR love, it could suggest (Jesus NEAR love) OR (Christ NEAR love)

That would be great

https://community.logos.com/discussion/comment/130722#Comment_130722

I'm wanting something that is relatively self-explanatory for the wiki.

How about this (not exactly brief, but still…):

Be careful using proximity operators when you have brackets in your search. Logos is not able to support using inner proximity operators which evaluate two outer terms. Human logic says (Jesus OR Christ) NEAR love means "search for either of the words Jesus or Christ near the word love". But Logos uses machine logic not human logic. Machine logic performs the search in the brackets first, and then carries out the rest of the search. It means "search for all the verses that contain either Jesus OR Christ. Then search for the word love near to that result". This doesn't work, because the proximity operator is evaluated last.

To avoid this problem, make sure you use proximity operators only in the outer terms of your search. In the case of the example above, the correct syntax is (Jesus NEAR love) OR (Jesus NEAR Christ)

Incidentally, I think this thread has shown than a lot of the logic on the WIki page is actually wrong. Don't misunderstand me, I've bookmarked the page, and use it often. The advice works - but not in these edge cases. In particular a comma is not equivalent to an OR, even though sometimes it functions that way, and I think that's confusing a lot of people.

I might have a go at creating a new page that will be a lot longer, and include some examples.

Kevin Becker

https://community.logos.com/discussion/comment/130774#Comment_130774

I might have a go at creating a new page that will be a lot longer, and include some examples.

Mark,

I've been thinking about starting some work on an advanced searching page but I've been concerned that whatever I came up with would be inadequate in some areas.

What would you think about taking a discussion like this over to Google Wave for the purpose of collaboratively drafting a wiki page that would provide much more specific help.

I don't mean to intrude if this is a project you want to take upon yourself. However, my experience with the update channel wiki page has got me thinking about how discussions and wranglings over how Logos works could be done better. I've found it difficult to originate a wiki page that easily allows for others to add to it without resulting in a cobbled together feel.

What do you think about it?

https://community.logos.com/discussion/comment/130778#Comment_130778

Kevin,

Thanks for the offer. I actually got started before I read your message. You can see the initial results here: http://wiki.logos.com/Temp_search_page- please make any suggestions you wish. It's not finished yet, but I'm going to be away from my computer for the next several hours.

Writing it has really helped me to understand the difference between commas and OR. And it was Dave's search page that helped me understand it! Commas are not equivalent to OR, they're lists! Once you've understood that lists are not ORs, everything is straightforward. This from my draft wiki page:

Using lists

Lists are a very useful feature which provide shortcuts in a number
of searches. A list is written like this: (term1, term2, term3,
etc.). When Logos encounters a list, it performs the search
using just term1. Then it repeats the search using just term2, then with
just term3, etc. Once it has finished, it then ORs the
results. Here are some examples:

(Jesus, Christ) is equivalent to Jesus
OR Christ
(Jesus, Christ) AND love is equivalent to (Jesus
AND love) OR (Christ AND love)*

Lists are most useful when used with fields (see
below), or when trying to ensure proximity operators are only used in
the outer terms of your search. For example:

The search described earlier (master NEAR love) OR
(master NEAR serve) OR (neighbor NEAR love) OR (neighbor NEAR serve)
can be simplified to (master, neighbor) NEAR (love, serve).
Logos treats the two lists separately, iterating through them until
every combination as been reached, like this:
- master NEAR love
- master NEAR
  serve
- neighbor NEAR love
- neighbor
  NEAR serve

Please note: Some people get confused as they equate the list
with the OR command. They are not the same, even though in a very basic
search they will perform in the same way. Remember, Logos iterates
through lists, then ORs the results.

Kevin Becker

https://community.logos.com/discussion/comment/130796#Comment_130796

Mark,

Nice work, some initial comments:

I would promote the Wildcard and Stemming sections above "Using Boolean Operators." Most of the confusion stems from combining Boolean and Proximity terms inappropriately. Placing them next to each other will aid those reading the page to figure out how this works.

Some users might be confused by calling ( ) brackets. I imagine most would call them parentheses. I know that it is mathmatically correct to call them brackets but perhaps a parenthetical comment that the parenthesis characters are being used would help anyone who might be confused. I mention this because I noticed that square brackets [ ] make the search engine do some wierd things. "[evidential OR presuppositional] AND apologetics" returned "and" in the search results. I'm not certain if this warrants a warning or a bug report though...

When you say "Just like in Maths" is Maths a typo or is it just a difference between British and American English?

https://community.logos.com/discussion/comment/130796#Comment_130796

You can see the initial results here: http://wiki.logos.com/Temp_search_page-

Wonderful! Thanks for all you guys are doing on this! Both of you need to be on the Logos payroll as technical writers. [:)]

I had not thought of them as lists. Does the list concept also work when using space as an "AND" operator?

Kevin Becker

https://community.logos.com/discussion/comment/130808#Comment_130808

Does the list concept also work when using space as an "AND" operator?

I don't think so.

I searched "love NEAR (heart soul)" It resulted in 0 hits. I also tried "(love god) AND (heart soul)" which confused the search engine, it thought "and" was a search term instead of an operator. "(love god) OR (heart soul)" only resulted in 1 verse, once again the search engine was confused, thinking that "or" wasn't an operator.

Using a space as AND is only helpful in a basic search for a string of words. If you are looking to introduce proximity or other boolean operators it becomes worthless.

(Mark do you think this info should go on the page?)