Reproducible Bug: Logos mangles a valid INTERSECTS search

Mark Barnes

I was looking to play with a recent search by Fred, but Logos completely misinterpreted my valid search:

(lemma:γυνή INTERSECTS <Sense wife>) AFTER 1 WORD @R

Logos interprets this as:

(lemma:γυνή INTERSECTS <Sense ~ wife>) AND "AFTER" AND @R

When I replace INTERSECTS with ANDEQUALS, Logos interprets the search correctly.

Find more posts tagged with

Comments

Fred Chapman

Hey Mark,

I see your point on INTERSECTS vs ANDEQUALS

Your ANDEQUALS search returns better results than the one I suggested. Yours removes a couple of garbage results that mine included. One thing that threw me was why yours was capturing so many more results, then I realized you were searching All Passages rather than just the Pauline Epistles.

Andrew Batishko

Logos completely misinterpreted my valid search:

(lemma:γυνή INTERSECTS <Sense wife>) AFTER 1 WORD @R

Logos interprets this as:

(lemma:γυνή INTERSECTS <Sense ~ wife>) AND "AFTER" AND @R

Generally the search engine doesn't support most operators as operands of a proximity operator. This is the same issue as mentioned here where the comma operator works but not the OR operator: https://community.logos.com/forums/t/4896.aspx

That said, in the same way that there is an exception for the comma operator, we should be able to make exceptions for the INTERSECTS and WITHIN operators. I've created a case to fix this.

SineNomine

That said, in the same way that there is an exception for the comma operator, we should be able to make exceptions for the INTERSECTS and WITHIN operators. I've created a case to fix this.

What about NEAR?

Andrew Batishko

What about NEAR?

Unfortunately, no. The difference is that the result of the INTERSECTS and WITHIN operators is a single matching term, while NEAR results in 2 matching terms. This prevents it from being able to be combined with the other proximity operators.

SineNomine

What about NEAR?
Unfortunately, no. The difference is that the result of the INTERSECTS and WITHIN operators is a single matching term, while NEAR results in 2 matching terms. This prevents it from being able to be combined with the other proximity operators.

OK.

Phil Gons (Logos)

Generally the search engine doesn't support most operators as operands of a proximity operator. This is the same issue as mentioned here where the comma operator works but not the OR operator: https://community.logos.com/forums/t/4896.aspx

That said, in the same way that there is an exception for the comma operator, we should be able to make exceptions for the INTERSECTS and WITHIN operators. I've created a case to fix this.

This now works in Logos 10.

Dave Hooton

This now works in Logos 10.

In Morph Search

(lemma:γυνή INTERSECTS <Sense wife>) AFTER 1 WORD @R is converted as

(lemma.g:γυνή INTERSECTS reference:sense:wife) AND text:AFTER AND morph.g:R

However, (lemma.g:γυνή INTERSECTS reference:sense:wife) AFTER morph.g:R seems to work correctly.

But lemma.g:γυνή INTERSECTS sense:wife AFTER morph.g:R works even better as the pronoun results are not counted

i.e. it is parsed as lemma.g:γυνή INTERSECTS (sense:wife AFTER morph.g:R)

Note that most users will not use reference:sense especially when it is not necessary.

The original with AFTER 1 WORD also works