Search Queries
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
Comments
-
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?0 -
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.
0 -
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
0 -
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
0 -
NOW how do I specify proximity? I get as far as BEFORE and AFTER in caps!
word1 AFTER/BEFORE/WITHIN n words/chars word2
0 -
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]
Dave
===Windows 11 & Android 13
0 -
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__
0 -
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".
0 -
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.
0 -
-
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:
Dave
===Windows 11 & Android 13
0 -
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
0 -
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.)
0 -
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. [:)])
0 -
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:-
But All Passages is the same as Bible isn't it?
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
0 -
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
0 -
Dave,
Here are my search times.
It's clear from this particular situation that "basic search" wins.
Robert Pavich
For help go to the Wiki: http://wiki.logos.com/Table_of_Contents__
0 -
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.
0 -
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
0
