Autocomplete optimizations for v24 Beta

For beta v24 we’ve made some experimental changes to how autocomplete suggests items. Please post your feedback/experience if you notice speed improvements or ranking changes with the below.

Prefix matching only on the last word when matching people, places, etc.
Not showing lemmas or roots when there are too many matches
Not showing people, places, etc. when there are too many matches
Not showing search terms when there are too many matches
Using flexible parsing with 10 Bible data types to determine whether the no-keyword text could be a Bible reference
A different technical approach to parsing non-keyword numbers
Only parsing 20% of non-keyword text when an author data type is in use

Find more posts tagged with

Comments

SineNomine

Sorry, I do not understand your post. Is this a list of things that Beta v24 has started doing, is still doing, has stopped doing, is trying to do...?

MJ. Smith

https://community.logos.com/discussion/comment/1248272#Comment_1248272

Its a list of changes between V23 and V24 beta i.e. 24 does them 23 does not

SineNomine

https://community.logos.com/discussion/comment/1248279#Comment_1248279

Its a list of changes between V23 and V24 beta i.e. 24 does them 23 does not

That's what I expected, but the original post is unclear.

Dave Hooton

In Bible Search

Prefix matching only on the last word when matching people, places, etc.

paul bible:"John 3:3"

Does that mean I get no suggestion for "paul" when inserted as shown? Behaviour seems to be the same as before.

Not showing lemmas or roots when there are too many matches

g:k has no suggestions.

g:l only shows roots. It would be better to have no suggestions

In both cases I have to type a second letter to get lemmas which seems reasonable to me.

j shows roots which are not expected.

Not showing people, places, etc. when there are too many matches

be shows lemmas & roots. But it does not show Bethel when other places are suggested.

Not showing search terms when there are too many matches

It seems to take too long to decide this vs simply showing terms e.g. a single letter input like a

Did you consider this time aspect?

Again, I prefer not to see lemmas/roots unless using a language prefix like g:

In Morph Search

Using flexible parsing with 10 Bible data types to determine whether the no-keyword text could be a Bible reference

"Apocalypse of Ezra will suggest pseudepigrapha:"Greek Apocalypse of Ezra" - with lemmas/roots (All Books) and with only its Topic (specific book).

"Apocalypse of elijah will suggest pseudepigrapha:"Apocalypse of Elijah" - with many roots (All Books) and with a few lemmas/roots (specific book).

Again, I'm not expecting lemmas/roots. And the behaviour can be erratic e.g. suggesting only the topic.

With all the above, I think a good dialogue will be necessary to understand your expectations.

Don't Understand

A different technical approach to parsing non-keyword numbers

Only parsing 20% of non-keyword text when an author data type is in use

Please help me understand these two.

Dave Hooton

https://community.logos.com/discussion/comment/1248720#Comment_1248720

This needs a Bump up.

Ed Ball (Logos)

https://community.logos.com/discussion/comment/1248720#Comment_1248720

Prefix matching only on the last word when matching people, places, etc.

This means that, for example, `soldiers arresting jes` will match the people group "Soldiers arresting Jesus", but `sol arr jes` will not. Matching every word as a prefix was generating too many results and hurting performance.

It would be better to have no suggestions

I'll record that suggestion: Don't show roots if we don't show lemmas.

But it does not show Bethel when other places are suggested.

Even when we return some places, we don't necessarily return them all, and we might not choose the "best" ones to keep. Hopefully we can better address that in the future.

It seems to take too long to decide this vs simply showing terms e.g. a single letter input like a

I agree, but I believe it is faster than it was. Hopefully we will continue to improve performance in the future.

I prefer not to see lemmas/roots unless using a language prefix like g:

I'll make sure this suggestion is recorded.

the behaviour can be erratic

True. These changes were to address some of the worst performance issues, but there is still a lot of room for improvement, both in performance and in behavior.

parsing non-keyword numbers

We no longer attempt to parse numbers (e.g. `12`) with every known data type, which improves performance.

parsing 20% of non-keyword text when an author data type

To improve performance, we no longer attempt to parse query text with every author data type, but rather restrict ourselves to a subset of author data types that are actually used.

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/1249543#Comment_1249543

I prefer not to see lemmas/roots unless using a language prefix like g:

I'll make sure this suggestion is recorded.

For English letters, concur with not showing original language lemmas/roots unless using untransliteration: e.g. h: g:

If entering/pasting original language letters, then would like to see lemmas/roots: e.g. שָׂ֣ם suggests 29 roots, but lacks root.h:שׂים in autocomplete from Isaiah 57:2 participle. h:sm also lacks root.h:שׂים suggestion while h:sym autocomplete shows two lemmas and root.h:שׂים

Greek word ἦν lacks suggestions of root.g:ειμι & lemma.g:εἰμί (ἦν in John 1:1 is an imperfect conjugation of εἰμί)

Context Menu for original language resources have root and lemma search suggestions. I can imagine an original language student copying a word & pasting into search being a bit disappointed by lack of relevant root & lemma in autocomplete suggestions.

Keep Smiling [:)]

Dave Hooton

https://community.logos.com/discussion/comment/1249579#Comment_1249579

Context Menu for original language resources have root and lemma search suggestions. I can imagine an original language student copying a word & pasting into search being a bit disappointed by lack of relevant root & lemma in autocomplete suggestions.

Don't understand. If selecting a root/lemma on the LHS, they get suggestions if Text is chosen as a "copy" on RHS??

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/1249762#Comment_1249762

Context Menu for original language resources have root and lemma search suggestions. I can imagine an original language student copying a word & pasting into search being a bit disappointed by lack of relevant root & lemma in autocomplete suggestions.

Don't understand. If selecting a root/lemma on the LHS, they get suggestions if Text is chosen as a "copy" on RHS??

Selection pop-up has surface text Copy (without lemma/root)

Clicking Search in Keyboard Selector Selection Menu opens a Bible Search for lemma.

FWIW: my demonstration account has Show Keyboard Selector set to Yes (default) while my purchased Logos has Show Keyboard Selector Show Selection Menu set to No (to avoid right click having two pop-up menus & my purchased preference for Context Menu).

FYI: appears Lexham Hebrew Bible (LHB), Lexham Hebrew-English Interlinear (LHI), & Biblia Hebraica transcripta (BHt) have both lemma & root in LHS of context menu. Other Hebrew Bibles: AFAT, BHW, BHS, ... only have lemma. AFAT morphology is used for Hebrew Bible and Dead Sea Scrolls.

Keep Smiling [:)]

Dave Hooton

https://community.logos.com/discussion/comment/1249775#Comment_1249775

I can imagine an original language student copying a word & pasting into search being a bit disappointed by lack of relevant root & lemma in autocomplete suggestions.

Selection pop-up has surface text Copy (without lemma/root)

That was not stated to be the origin of "copying" for your "original language student". However, I think your student would be smart enough to learn that lemma/root suggestions don't come from a manuscript word!

FWIW: I have Show Selection Menu = NO.

Clicking Search in Keyboard Selector opens a Bible Search for lemma.

Really! I couldn't find a Search option.

FWIW: my demonstration account has Show Keyboard Selector set to Yes (default) while my purchased Logos has Show Keyboard Selector set to No (to avoid right click having two pop-up menus & my purchased preference for Context Menu).

This is really confusing.

"two pop-up menus" - where/how?

"my purchased preference for Context Menu" - ??

FWIW: I have Show Keyboard Selector = NO.

MJ. Smith

https://community.logos.com/discussion/comment/1249543#Comment_1249543

Matching every word as a prefix was generating too many results and hurting performance.

Guess what! I don't care about performance when I can't get the appropriate entry. As long as you keep front and back matches independent, the results are too often garbage. As long as the recognized values lack consistency, the results are too often garbage. Sure you can tweak the performance but garbage results still belong in the trash can and the inability to get the desired entry creates frustration.

MJ. Smith

https://community.logos.com/discussion/comment/1249543#Comment_1249543

I prefer not to see lemmas/roots unless using a language prefix like g:

I'll make sure this suggestion is recorded.

or the greek or hebrew or syriac alphabet is used. Not everyone uses transliteration.

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/1249907#Comment_1249907

Clicking Search in Keyboard Selector Selection Menu opens a Bible Search for lemma.

Really! I couldn't find a Search option.

Keep Smiling [:)]

MJ. Smith

https://community.logos.com/discussion/comment/1249949#Comment_1249949

Er..ah.. you're showing the selection menu when you said keyboard selector. I suspect that is why Dave is confused. I certainly am.

To have the selection menu use lemma you must have prefer lemma set in program settings.

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/1249907#Comment_1249907

"two pop-up menus" - where/how?

While trying to replicate Passage List issue for thread => Passage List Bug - Desktop Software Version 23.1.33 using Verbum 24.0.7 on macOS Monterey 12.6.3 (demonstration account) I had highlighted Deuteronomy 16:13-15 that showed Deuteronomy 16:13-1 in LEB tab:

Left click after rejoicing to clear verse selection followed by right click on rejoicing (wanting to see Deuteronomy 16:15 reference) has pop-up menus for Keyboard Selector Selection Menu & Context Menu:

Clicking "..." in Keyboard Selector Selection Menu causes both pop-up's to disappear and open a new Context Menu displaced to the right.

Search tab has Bible Search for thanks OR rejoice in LEB by verse with results shown in Passages.

"my purchased preference for Context Menu" - ??

FWIW: I have Show Keyboard Selector = NO.

My purchased account also has Show Keyboard Selector = NO & Show Selection Menu = NO

Context Menu has one less highlighter option (green) compared to Keyboard Selector Selection Menu.

To have the selection menu use lemma you must have prefer lemma set in program settings.

Confirmed Prefer Lemma = Yes in program settings (of my demonstration account).

Keep Smiling [:)]

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/1249960#Comment_1249960

Did you read my post? You are NOT talking about the keyboard selector.

[:$] so edited my replies keyboard selector Selection Menu

In LEB, I unchecked Visual Filters and closed most tabs, Replicated Selection Menu & Context Menu both appearing using Verbum 24.0.7 on macOS Monterey 12.6.3

For grins, closed Search tab followed by selecting text in Deuteronomy 16 (replicated LEB tab showing Deuteronomy 16:13-1 that lacks last #)

Only Selection Menu appeared. Clicked above circle (after rejoicing) to clear selection followed by right click on rejoicing has both Selection Menu & Context Menu:

Keep Smiling [:)]

MJ. Smith

https://community.logos.com/discussion/comment/1249968#Comment_1249968

so edited my replies keyboard selector Selection Menu

Thank you.

Dave Hooton

https://community.logos.com/discussion/comment/1249960#Comment_1249960

"two pop-up menus" - where/how?

While trying to replicate Passage List issue for thread => Passage List Bug - Desktop Software Version 23.1.33 using Verbum 24.0.7 on macOS Monterey 12.6.3 (demonstration account) I had highlighted Deuteronomy 16:13-15 that showed Deuteronomy 16:13-1 in LEB tab:

...

...

We really did not need this lengthy "aside" on issues not relevant to the thread. I asked for a clarification of

Context Menu for original language resources have root and lemma search suggestions. I can imagine an original language student copying a word & pasting into search being a bit disappointed by lack of relevant root & lemma in autocomplete suggestions.

Why would your "original language student" be disappointed after pasting a surface/manuscript word?

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/1249982#Comment_1249982

Why would your "original language student" be disappointed after pasting a surface/manuscript word?

Surface/manuscript has spelling conjugation/declination. Autocompletion suggestion for שָׂ֣ם OR h:sm (transliteration) simply lacks root.h:שׂים for שָׂ֣ם in Isaiah 57:1 LHB while having 29 root suggestions for שָׂ֣ם whose first two letters are שָׂ֣ם OR 31 root suggestions for h:sm whose first two letters match h:sm. Dozens of autocompletion suggestions, but disappointed by none of them having the correct Hebrew root for a surface/manuscript word

Another source for original language copy & paste is grammar resource(s), whose Context Menu does not have lemma nor root => only can search for surface text. An example is autocomplete for אברהם suggesting lemma & surface text:

Context Menu in LHB shows six roots:

Keep Smiling [:)]

Dave Hooton

https://community.logos.com/discussion/comment/1249985#Comment_1249985

Autocompletion suggestion for שָׂ֣ם OR h:sm (transliteration) simply lacks root.h:שׂים for שָׂ֣ם in Isaiah 57:1 LHB

I believe that h:sym is the correct transliteration for root.h:שׂים

An example is autocomplete for אברהם suggesting lemma & surface text:

The suggestions for the two words שָׂ֣ם and אברהם appear to be inconsistent/lacking.