I believe these problems prevent L4 from having a search capability equivalent to L3, especially in the absence of a Graphical Query. The background to this can be found at http://community.logos.com/forums/p/4835/38571.aspx#38571
Dave,
Can't you just stick with the script and say "Logos 4 sucks! I was tricked! I want my money back!"
Instead of a clear, detailed, level-headed post that asks specific questions?
[:D]
Someone has to set an example[:P]
Could you add this to the Wiki? It's important, but it looks like it's been forgotten.
http://wiki.logos.com/Basic_Wiki_Formatting
The wiki allows each of us to decide what is important and then do the work to make it happen.
Again, maybe someone will post what you ask, but I wanted to encourage you to learn it and help contribute instead of just adding tasks for others to do. :-)
morph terms in a list give wrong results eg. (@N, @C) BEFORE 3 words lemma:εἰμί morph terms OR'd give wrong results eg. (@N OR @C) BEFORE 3 words lemma:εἰμί
I'm unable to reproduce the first problem; can you give an example? We're aware of the second problem and have a case open for it in our bug database.
morph terms in a list give wrong results eg. (@N, @C) BEFORE 3 words lemma:εἰμί morph terms OR'd give wrong results eg. (@N OR @C) BEFORE 3 words lemma:εἰμί I'm unable to reproduce the first problem; can you give an example? We're aware of the second problem and have a case open for it in our bug database.
Don't comma and OR mean the same thing? (So that the two examples given by Dave should have the same results and would be related to the same bug?)
exclusion/negation of a morph term does not work eg. -@D In L3 ~[=D???] exclusion/negation of a list term does not work eg. (who*, -whom). In L3 (who*, ~whom).
Exclusion syntax is not supported by the Logos 4 search engine. Adding support for exclusion within term lists probably wouldn't be too hard, at which point the first query could be simulated with something like (@*, ~@D) (if morph wildcards without a part of speech are supported, which would be a different thing to look in to). I've created cases for these issues.
No, they're slightly different (for some technical reasons that I won't go into), but different enough that the first query is parsed successfully. Actually... I think I might have some non-shipping code (in progress to fix a different bug) on my machine that caused the first query to work, so Dave's report is probably correct.
inclusive terms are counted as exclusive in a list eg. (who*, whom) is counted as the results for who* + results for whom. L3 treats correctly ie. results for who* only.
Good catch; I've filed a bug.
wildcard * processing is slow eg. who* wildcard ? does not work (is not implemented)
The first issue probably depends on a lot on the speed of the computer, the size of the library, and the specificity of the term (e.g., "a*" vs "Eleaza*").
? works fine as a wildcard term for me: "go?d" finds good, gold, etc.
Don't comma and OR mean the same thing? (So that the two examples given by Dave should have the same results and would be related to the same bug?) No, they're slightly different (for some technical reasons that I won't go into), but different enough that the first query is parsed successfully.
No, they're slightly different (for some technical reasons that I won't go into), but different enough that the first query is parsed successfully.
Being technically minded, can you point me to an explanation of the difference? Is it a question of operator precedence?
In 4.0a SR-2 searching LGNTI in the Gospels (Matt-John):
@N BEFORE 3 words lemma:εἰμί ==> 1206/505
@C BEFORE 3 words lemma:εἰμί ==> 1024/453
(@N BEFORE 3 words lemma:εἰμί) OR (@C BEFORE 3 words lemma:εἰμί) ==> 2230/765 [as expected]
The two "abbreviated" expressions have incorrect results:-
(@N, @C) BEFORE 3 words lemma:εἰμί ==> 301/33
(@N OR @C) BEFORE 3 words lemma:εἰμί ==> 338/38
Note that: (@N BEFORE 3 words lemma:εἰμί), (@C BEFORE 3 words lemma:εἰμί) ==> 936/193
It does now! It didn't when I originally compiled the list.
