Search Queries

Dave Hooton
Dave Hooton MVP Posts: 35,776
edited November 20 in English Forum

Lemma searching appears to be morphology bound eg.

  • <Lemma = mr/el/ἀστοχέω>
  • <Lemma = lbs/el/ἀστοχέω>

How do I search ALL morphologies?

If query the word why do I get zero results? e.g.

  • ([lang el] ἀστοχέω) 
  • ἀστοχέω

One request coming from v3 was to have all options available in the Search box, so I'm disappointed that once again we have to select Grid | Verses | Aligned after the fact.

Dave
===

Windows 11 & Android 13

Tagged:

Comments

  • Bob Pritchett
    Bob Pritchett Member, Logos Employee Posts: 2,280
    Here's the thinking:

    Grid | Verses | Aligned are just different views of the same data. Putting them in the search specification would clutter up the search spec, and make it look as if you had to re-run the search to choose the presentation of results. Putting them in both places would add the confusion of having two places to do the same thing.

    Why do you want them in the search box? To save them as part of the search history? Because the app isn't correctly choosing or remembering the setting you want?
  • Bradley Grainger (Logos)
    Bradley Grainger (Logos) Administrator, Logos Employee Posts: 11,969

    How do I search ALL morphologies?

    If query the word why do I get zero results? e.g.

     

    The syntax for searching all morphologies should just be <lemma ἀστοχέω>, but that may not be working in Beta 1.

    You get zero results when searching for the lemma for the same reason that you get zero results when querying for "795" or "G795". Unlike LDLS3, lemmas are not indexed as words in the search index; they are indexed as data type references. And just as a data type reference query (currently denoted using angle brackets, e.g., <G795>) is necessary to find Strong's numbers, an angle-bracket delimited query is necessary to find lemmas. As for the unwieldy syntax, see point 1.

  • Dave Hooton
    Dave Hooton MVP Posts: 35,776

    The syntax for searching all morphologies should just be <lemma ἀστοχέω>, but that may not be working in Beta 1.

    It is not working with or without "=" as operator

    lemmas are not indexed as words in the search index; they are indexed as data type references.

    OK!

    • ([lang el] ἀγάπη)  or
    • ἀγάπη

    work for manuscript text. The first format comes from the Search box, the second comes from a bible's context menu (by selecting Greek). It is interesting that a Reverse Interlinear eg. ESV will be searched successfully but the Reverse Interlinear cannot initiate the search as the Greek option is not presented (only the Lemma). Some consistency would be appreciated.

    Also, the [lang el] option might be more efficient for searching Reverse Interlinears.

    NOW how do I specify proximity? I get as far as BEFORE and AFTER in caps!

    Dave
    ===

    Windows 11 & Android 13

  • Dave Hooton
    Dave Hooton MVP Posts: 35,776

    Here's the thinking:

    Grid | Verses | Aligned are just different views of the same data. Putting them in the search specification would clutter up the search spec, and make it look as if you had to re-run the search to choose the presentation of results. Putting them in both places would add the confusion of having two places to do the same thing.

    Why do you want them in the search box? To save them as part of the search history? Because the app isn't correctly choosing or remembering the setting you want?

    Because I don't want the application second-guessing my preferences, and because I may want to change the presentation occasionally, I would like the options to be available before I perform a search ie. after you click the magnifying glass for a new search. That could be accomplished  by always showing

    Grid Verses Aligned

    at the top of the results panel (followed by BIBLE RESULTS after the search) OR at the bottom of the search spec!

    Further, I would like the option (Simple List in v3) of not showing the text of the result ie. links only UNLESS you can dramatically improve the performance beyond the current v3 level!

    Dave
    ===

    Windows 11 & Android 13

  • Bradley Grainger (Logos)
    Bradley Grainger (Logos) Administrator, Logos Employee Posts: 11,969


    NOW how do I specify proximity? I get as far as BEFORE and AFTER in caps!


    word1 AFTER/BEFORE/WITHIN n words/chars word2

  • Dave Hooton
    Dave Hooton MVP Posts: 35,776

    word1 AFTER/BEFORE/WITHIN n words/chars word2

    It's not working! But are these real words or v3 words?

    law BEFORE good in the NT took a dismal 350 and 380 secs on successive runs when searching 27 English Bibles (incl. OT Tanakh). v3 took less than 50 seconds. It took 289 seconds after I removed the interlinear bibles (ESV, NASB95, NKJV, NRSV, LEB) - don't know what that proved as times were still dismal!

    Single word searches weren't impressive either  - Law took 182 seconds in the set minus interlinears.

    Law OR good took 410 secs in the original 27 bibles and the results grid was misaligned (below).

    [Win 7 on Athlon XP 2.16 GHz, 1.25 GB memory]

     

    image

    Dave
    ===

    Windows 11 & Android 13

  • Robert Pavich
    Robert Pavich Member Posts: 5,685 ✭✭✭

    What's the deal with these searches?

    Bradley; you searched a HALF MILLION articles in 14 seconds...for 8 search terms...and this takes 8 minutes????

    Robert Pavich

    For help go to the Wiki: http://wiki.logos.com/Table_of_Contents__

  • Bradley Grainger (Logos)
    Bradley Grainger (Logos) Administrator, Logos Employee Posts: 11,969


    It's not working!

    What in particular is not working? What did you search for? What did you get? What did you expect?

    But are these real words or v3 words?


    Try it and see... [:)]

    Note that "BEFORE 3 WORDS" allows the first search term to be 1 to 3 words before the second. (We figured that if you said "BEFORE 50 WORDS" you weren't looking for exactly 50, but were establishing the upper range.) If you need to find occurrences of "a" where it's exactly three words before "b", search for "a BEFORE 3-3 WORDS b".

  • Bradley Grainger (Logos)
    Bradley Grainger (Logos) Administrator, Logos Employee Posts: 11,969


    What's the deal with these searches?

    Bradley; you searched a HALF MILLION articles in 14 seconds...for 8 search terms...and this takes 8 minutes????


    So... the curious thing about the unoptimised search engine is (and I'm not making this up) it often takes longer to search less content than it does the entire library. I just repeated Dave's search on my P4 3.4GHz, 3GB RAM.

    • Bible Search, English Bibles, NT only: 170.0s
    • Bible Search, English Bibles, All Passages: 129.6s
    • Basic Search, Entire library: 7.4s

    This is an item we have on our list of things to tackle.

  • Dave Hooton
    Dave Hooton MVP Posts: 35,776

    What in particular is not working? What did you search for? What did you get? What did you expect?

    Note that "BEFORE 3 WORDS" allows the first search term to be 1 to 3 words before the second.

    This seems standard v3 syntax but see below:

     

    image

     

    image

    image

     

    Dave
    ===

    Windows 11 & Android 13

  • Dave Hooton
    Dave Hooton MVP Posts: 35,776

    This seems standard v3 syntax but see below:

    Also standard v3 is the default STEMMING, and there had been many requests to make this an Option with default of NO. The interface might get cluttered but it is needed in place of arcane modifiers like nostem() or exact(). And Grid Verses Aligned also needs to be up there for reasons I gave in a response to Bob Pritchett.

    Dave
    ===

    Windows 11 & Android 13

  • Bradley Grainger (Logos)
    Bradley Grainger (Logos) Administrator, Logos Employee Posts: 11,969


    This seems standard v3 syntax but see below:

    So it appears I led you greatly astray (but helped find a bug in the process!). Whereas operators need to be uppercase, the proximity unit is strangely required to be lowercase! Changing it to "words" allows the search to succeed. (We will fix this in an upcoming to prefer uppercase units, for consistency, but allow lowercase where it's not ambiguous.)

    image


     

  • Bradley Grainger (Logos)
    Bradley Grainger (Logos) Administrator, Logos Employee Posts: 11,969


    Also standard v3 is the default STEMMING, and there had been many requests to make this an Option with default of NO. The interface might get cluttered but it is needed in place of arcane modifiers like nostem() or exact().


    We listened: turn it off forever with "Match all word forms" on the panel menu. (Sorry, we're not going to make the default "No"; we feel that searching across the entire library generally returns more relevant results (especially for a "bag of terms" query) with stemming on. You'll notice that even Google's following our lead and doing it. [:)])

    image

  • Dave Hooton
    Dave Hooton MVP Posts: 35,776

    So it appears I led you greatly astray (but helped find a bug in the process!). Whereas operators need to be uppercase, the proximity unit is strangely required to be lowercase! Changing it to "words" allows the search to succeed.

    I thought I had tried lower case but probably used mixed case Words instead!

    My equivalent search took 2 seconds (1.9 to 2.09), but i then experimented with

    law BEFORE 3 words good

    because I wanted to set a trap for Ro 7:16 "law that it is good"! As expected v3 fell for it and v4 passed the test, and confirmed it with

    law BEFORE 4-4 words good

    Finally we have real word (accurate) proximity unlike the calculated word of v3!!!

     

    As for performance check the following:-

    image

     

    image

     

    image

    But  All Passages is the same as Bible isn't it?

    image

    Well -- same results!

    It's clear that we need to search All Passages for quick Bible searches rather than a range (Bible, New Testament) until Logos has done some optimisation!

    Dave
    ===

    Windows 11 & Android 13

  • Dave Hooton
    Dave Hooton MVP Posts: 35,776

    We listened: turn it off forever with "Match all word forms" on the panel menu. (Sorry, we're not going to make the default "No"; we feel that searching across the entire library generally returns more relevant results

    I'm glad you listened and sorry I didn't look too far! Does "Match all word forms" apply only to English stemming?

    Dave
    ===

    Windows 11 & Android 13

  • Robert Pavich
    Robert Pavich Member Posts: 5,685 ✭✭✭

    Dave,

    Here are my search times.

    It's clear from this particular situation that "basic search" wins.

    image

    Robert Pavich

    For help go to the Wiki: http://wiki.logos.com/Table_of_Contents__

  • Bradley Grainger (Logos)
    Bradley Grainger (Logos) Administrator, Logos Employee Posts: 11,969

    I'm glad you listened and sorry I didn't look too far! Does "Match all word forms" apply only to English stemming?

     

    It applies to stemming in all supported languages (which I think is also Spanish and German in Beta 1; there will be more languages later). At the moment, unchecking "Match all word forms" still allows accents that are not part of your language's alphabet to be ignored; for an English user, a query for "a" would match "å"; this would not happen for a Swedish user.

  • Dave Hooton
    Dave Hooton MVP Posts: 35,776

    It's clear from this particular situation that "basic search" wins

    Basic Search wins on time but doesn't provide the same results because it searches across verse boundaries e.g. "70 law. 71 My punishment was good" Ps 119:70-71, GNT.  But 5 other bibles (in my collection) incorrectly contributed  "law. It is good" for Ps 119:70-71! Can you see why?

    Here are the bibles that provide the same result  "law. It is good"  at Ps 119:70-71 from two Basic queries:-


     law BEFORE 4-4 words good   law BEFORE 3-3 words good
    Darby ESV
    ASV KJV
    AV1873 NET
    RSV NIV
    TNIV NKJV

    NASB95

    NRSV

    Dave
    ===

    Windows 11 & Android 13