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. :-)
Joe,
I fought vociferously for us to have bug tracker. Now we've got one on the wiki I'm trying to spread the news that it's there and encourage everyone to use it. Perhaps its laziness on my part, but I think generally it's better for those reporting bugs to take responsibility for adding them.
Mark
I just added it to the Wiki.
Happy to take a minute to do that in appreciation for all the time that both Dave and Mark have saved me with their contributions to this forum.
I am especially grateful to Mark for his very helpful videos here and here as well as his contribution of a Bibliographic Report generator here.
Not to mention his willingness to fix my preferences database so I could use the Cited By tool after Beta 3 broke it.
I fought vociferously for us to have bug tracker.
Sorry but I have no confidence in wiki bug trackers, especially this early in a release. There's too much room for entering "bugs" that are simply not knowing how to use the software and too many "bugs" that are a description of the surface symptoms in which the root bug has already been listed (many) times. It would be far better for Logos to provide a list of bugs (and features) that we no longer need to report because they've already heard it 52.3 times.
Sorry but I have no confidence in wiki bug trackers, especially this early in a release.
As the Wiki is community edited, what you're saying is that you have no confidence in the community. I disagree. 'Proper' bug tracking software would be better, but the wiki page works reasonably well, and is light years ahead of this forum for that specific purpose. It is all very well saying Logos should give us a list of bugs they know about. I guess the purpose of the wiki is for us to give Logos a list of bugs they may not know about. We take on some responsibility in the hope that will get bugs fixed quicker.
Thanks for that Russ. I think this is the best way to work rather than dropping reminders all over the place. Sorry, Mark but you'll find that most users are just happy to report a problem and may be discouraged from doing so if we impose an additional burden.
I'm trying to get around to the bugs I reported in secret beta.
There's too much room for entering "bugs" that are simply not knowing how to use the software and too many "bugs" that are a description of the surface symptoms in which the root bug has already been listed (many) times
See my comments at http://community.logos.com/forums/t/5969.aspx?PageIndex=3
The root bug really isn't our concern but an experienced user would have the ability to relate different issues to the same cause eg. a number of searches were reported as not working with 4.0a B2 but an astute observer simply asked if they had just merged or indexed their resources!
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?
Currently: the comma takes its two operands and constructs one term from them, while OR takes its two operands and creates a Boolean node. (4.0b will also colour these and one and two terms, respectively.) The proximity operators can only operate on terms, not Boolean nodes (because (a AND b) BEFORE (c AND d) doesn't have an obviously "right" interpretation); the net effect is that WITHIN can have the comma operator as one of its operands, but not the OR operator. The distinction is rather subtle, so we'll probably just end up allowing either operator to be typed in, and internally use the right processing that makes sense for the current context.
The distinction is rather subtle, so we'll probably just end up allowing either operator to be typed in, and internally use the right processing that makes sense for the current context.
It helps to be consistent with L3 and regard comma as a "shortcut" for OR - people are used to this after constructing queries for Library & Collections (where there is no need for proximity ops).
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.
