ANDEQUALS search anomaly
I am trying to figure out why a search using the ANDEQUALS operator would produce more matches than a search for a single search term.
I am searching the Lexham Syntactic Greek New Testament for Predicate Nominatives. Here are my results using the Bible search:
- Search 1: A Bible search for <SGNTSyntacticForce = predicate nominative>. This produces 1445 results.
- Search 2: Narrow this search to only nominative nouns. I changed the Bible search to ([field bible, content] <lbs-morph+el ~ NN???>) ANDEQUALS <SGNTSyntacticForce = predicate nominative>. This produces 1904 results. Why should a narrower search using ANDEQUALS produce more hits than a single term search?
If I understand the ANDEQUALS operator correctly, this should limit the results to a word that is both a Noun and tagged as a Predicate Nominative and thus produce few matches than all words that are tagged Predicate Nominative.
Now let's try the same thing using the Syntax search, which uses the visual search design.
- Search 3: Syntax search for a single word tagged Predicate Nominative. This produces 1444 results. I am not sure why it has one less match than the command line search.
- Search 4: Syntax search for a single word tagged Predicate Nominative and case "nominative" and part of speech "noun". This produces 952 results. This is more in line with what I would expect, since there are some participles and other substantives that are predicate nominatives.
There may be mysteries here in how the Lexham Syntactic Greek New Testament. But I am surprised at how a ANDEQUALS search could broaden the results rather than narrow them.
Comments
-
Harry Hahne said:
- Search 1: A Bible search for <SGNTSyntacticForce = predicate nominative>. This produces 1445 results.
- Search 2: Narrow this search to only nominative nouns. I changed the Bible search to ([field bible, content] <lbs-morph+el ~ NN???>) ANDEQUALS <SGNTSyntacticForce = predicate nominative>. This produces 1904 results. Why should a narrower search using ANDEQUALS produce more hits than a single term search?
The search counts one result for each term. With two terms you have 1904 / 2 = 952 distinct results which you can now compare with 1445, showing that the search is indeed narrowed. But the immediate way to see this is 1445 results in 1119 verses vs 1904 in 755 verses.
I disagree with the way Logos count ANDEQUALS results but they haven't seen the light in over 3 years of trying!
Dave
===Windows 11 & Android 13
0 -
Dave Hooton said:
The search counts one result for each term. With two terms you have 1904 / 2 = 952 distinct results which you can now compare with 1445, showing that the search is indeed narrowed.
I see what they are doing. I agree with you, that this does not make sense for the ANDEQUALS operator, since there is only one search term. ANDEQUALS means to find 2 characteristics of the same search term.
Nevertheless, the number seems to be reported correctly with the Syntax search (except for the minor difference between 1444 and 1445, which I cannot account for).
The problem with this type of miscounting of hits is that it throws off the value of any statistical calculations, such as with the Graphical Search results. It is really a disaster when you have multiple search terms with the AND Boolean operator, since Logos counts multiple combinations of matches. It has been a while since I looked at it, but if you have 2 search terms and 2 instances of the second search term in a verse, Logos counts this as "4 results", since it matches up the combinations of the 3 words. See, for example, @NV BEFORE @NVP on 1 John 2:14. Yet strangely, it does not consider every possible combination of matches. For example, @NV BEFORE @NV on 1 John 2:14 still counts as 4 results. It appears not to consider the second vocative noun in combination with the third vocative noun as a valid combination. So it is very hard to actually predict how Logos is going to count "results" with Boolean searches.
Dave, it seems like you and I have a running conversation about these types of searches. Thanks for your rapid responses to my questions. I appreciate the insight of your experience with the dark subtleties of Logos. [:D]
0 -
Harry Hahne said:
I appreciate the insight of your experience with the dark subtleties of Logos.
You're welcome, Harry.
Dave
===Windows 11 & Android 13
0 -
Hey brothers, maybe you could help, this doesn't work. I think this is pretty simple. Do you know an easiest way to have some results?
@CLI ANDEQUALS therefore
0 results in L6
Thanks in advance.
0 -
Josué Pineda said:
@CLI ANDEQUALS therefore
Welcome [:D]
Try searching for:
@CLI WITHIN 0 WORDS therefore
Keep Smiling [:)]
0 -
Thanks a lot. I saw another post of yours and I found this solution.
(@CLI) ANDEQUAL therefore
I don't know what is the difference of adding the parenthesis.
0 -
Josué Pineda said:
I don't know what is the difference of adding the parenthesis.
Terms in parentheses are usually evaluated first. It must cause @CLI to be properly evaluated wrt ANDEQUALS
Dave
===Windows 11 & Android 13
0 -
Josué Pineda said:
Hey brothers, maybe you could help, this doesn't work. I think this is pretty simple. Do you know an easiest way to have some results?
@CLI ANDEQUALS therefore
0 results in L6
Thanks in advance.
The Wiki says:
Please note: ANDEQUALS and NOTEQUALS do not work in morphological searches if you use the @sign. If you are searching for lemmas you may not need to use ANDEQUALS, as you can use the lemma field instead (e.g. lemma:γλῶσσα@NGSF). For other searches you can use one of two workarounds:
- Use the LogosMorph reference: Instead of searching for @NGSF ANDEQUALS tongue, search for <LogosMorph = NGSF> ANDEQUALS tongue.
- Use WITHIN 0 WORDS: Instead of searching for @NGSF ANDEQUALS tongue, search for @NGSF WITHIN 0 WORDS tongue.
I've updated it now to include the parentheses workaround.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
I tried this:
(([field bible, content] <LogosMorphGr ~ C?>) ANDEQUALS ([field bible, content] also))
and it worked better. Almost perfect [:D]. Sometimes duplicates results.
0 -
SQL is easier. [<:o)]
0
