Letter search not yielding full results

[TYA]

Blessings all.

 

I see no reason why the letter search / literal search in this image (attached) doesn't give the Samaritan Pentateuch for "Jeshurun."

 

I wrote probably more than I needed to in the screenshot (out of frustration), but the main thrust of this post is that a letter / literal search fails to yield the Samaritan Pentateuch, which uses the same exact Hebrew word as the BHS in verses like Deu 32:15 and Deu 33:5.  (See the second screenshot attached proving this point).

 

Accordance: please accept this as another sincere, firm request for a truly literal search (in addition to the already-powerful search engine), which considers *only* the letters inputted (unless additional vowel option added too), but which *doesn't* revolve around the root, lexeme, or tag.

 

In other words, please add a truly literal search that covers *all* texts (for that language) in Accordance.  I know such a thing exists and is possible, because other programs yield true literal searches across all texts.  That would be greatly appreciated. 

Edited October 7, 2018 by TYA

[TYA]

Accordance, you rock!   I revisited this topic just to see if anything behaved differently with the new release of 12.3.0 (after reading the full changelog with excitement), and it seems that this new release totally solved / addressed the complaint I posted above.  Yay!  See the attached screenshot below, and compare it to those above, if you are interested.

 

P.S. I can't even say how excited and appreciative I am for the new "Text Browser."  As Miketisdell already noted since the release, this approximates that vital function I enjoy in BibleWorks, and it makes all the difference for me in Accordance.

 

I have been filling up the height of my context menu in Accordance with all the Workspaces I've been creating, some of which are only because the Workspaces contain a maximum number of versions (i.e. no vertical scroll bar).  I do appreciate the Workspaces, but I'm used to being able to look at 50 versions in various languages in BibleWorks, *and* with tagging information available.  Now I can do all that in Accordance with the "Text Browser" feature!

 

I've never been more impressed by the listening and response of a Bible software company.  Admittedly, I don't pester every other software company like I do Accordance (LOL), but that's only because I know that Accordance is serious about being the best, and making things even better.  This company, team, and software is wonderful.

Edited November 1, 2018 by TYA

[TYA]

I'd like to add, however, that I would still like the literal Hebrew search to *not* include prefixes (bet, lamed, vav) unless I either 1) specifically include the prefix in my search, or 2) use a wildcard (? or *) to intentionally broaden the search to include prefixes.  Then, I could say that the search is *truly* literal (while also allowing wildcards to broaden it).

Edited November 1, 2018 by TYA

[Λύχνις Δαν]

I'm not sure I'm quite following you here TYA. Do you mean that you don't want the search to return hits for words that have the prefix even though the search string appears in such words. To clarify by example, if I search for בבית I get a bunch of hits of course all including the prefix ב. If I search for בית on its own I still get those hits that include the prefix Gen 27:15 for example though the prefix letter is not highlighted. Is it these you wish to exclude ?

 

Thx
D

[TYA]

 

Do you mean that you don't want the search to return hits for words that have the prefix even though the search string appears in such words. To clarify by example, if I search for בבית I get a bunch of hits of course all including the prefix ב.  

If I search for בית on its own I still get those hits that include the prefix ...

 

Exactly.  Simply put, if a search is truly literal, then it will find *only* what is being searched for, and nothing else.

 

There are several reasons why this is important.  Prefixes and suffixes have meaning, of course, and so I don't want--at least, when I'm doing *literal* searches--the software trying to dictate anything to me.  Many times I do manual lexical analysis to determine patterns among certain prefixes or suffixes.

 

Here, for the sake of demonstrating the importance of this, is just one of many examples I could provide:

 

I have been researching the origin and etymology of the Aramaic word מריא (marya), in which it is sometimes possible that the final א indicates an emphatic form of the word מרא ("lord / master"); but other times, this particular spelling denotes a direct translation (actually substitution) for the Divine Hebrew Name, יְהוָה.  That is, of course, a huge difference, and can have major theological implications in the passage.

 

This particular example manifests itself in research of Dead Sea Scrolls, Biblical Aramaic (Daniel), and the Peshitta Tanakh translation (ca. 100BCE-100CE), and the Peshitta Apostolic Writings (i.e. "NT"; ca. 150-200 CE).  That's a lot of material, and still others could potentially be included.

 

Now, if I'm subject to a pre-established grammatical database when it comes to getting search results--when I'm specifically trying to do a literal search--then how will I ever be able to find what I want (and *only* what I want)?

 

This is just one example; and bottom line, I can't perform fully effective lexical analysis when the software is adding, or dictating something back to me that I didn't ask for (at least, in my mind, you understand).  Examples could be multiplied when it comes to the bet, lamed, and vav prefixes (and definite article) in Hebrew.

 

So put plainly, a truly literal search will always return *only* what I input, 100% of the time.  After all, if I then want to broaden the search to include a prefix or suffix, I should be able to simply add a wildcard (? or *).  Make sense?

 

Accordance Team: I'm not suggesting changing or removing the already-great options and filters for searching, such as the grammatical searching mechanism.  But as I said in previous threads regarding the fact that Tools need to have an "All" filter for those of us who don't want Accordance forcing us to choose "Titles," "Scripture, "References," etc., for English content, so also it is the case here with original language searching: a *truly literal* option should be added / available for Hebrew / Aramaic / Greek.

Edited November 1, 2018 by TYA

[TYA]

Do you mean that you don't want the search to return hits for words that have the prefix even though the search string appears in such words. To clarify by example, if I search for בבית I get a bunch of hits of course all including the prefix ב.  If I search for בית on its own I still get those hits that include the prefix ...

 

To answer a second time (first see my most recent post above), here is yet another perfect example--and one I just came across tonight unintentionally--of why a *truly* literal search would be beneficial:

 

The Samaritan Pentateuch used by Accordance has variant readings in it (and it differs from another version I also have).  The variants in the Accordance version are apparently denoted by [א] and [ב] used within the text itself (e.g. Exo 11:3; see attached image).  I'm now trying to hunt down all occurrences of such variants by searching for [א] and [ב].

 

Granted, I admit I'm a newby with Accordance' search, and someone might be able to do this better; but since I can't search using the brackets (as they are functional search symbols), I figured that a literal search could be used to find the א and / or the ב isolated all by themselves.

 

Note: this method works perfectly in BibleWorks, which does allow a truly literal search.  But it doesn't work in Accordance, because even though I'm selecting "literal" in the search / Research window, Accordance wants to find every instance of these letters *within a string of characters.*  That, of course, is not "literal."  That is literal, plus anything else around it.  (Again, see my post above on why prefixes and suffixes shouldn't be added to a literal search when they aren't specifically asked for).

 

If someone knows how I could find all these occurrences of [א] and [ב] in the text, then I'd be grateful to know.  I can't imagine that there isn't a way to do it, but I'm just pointing out that one potential way--viz., a truly literal search--doesn't work in Accordance because it isn't yet available.

 

Please don't take this as negative.  Only a little frustrating, and another reason to add to my request for a truly literal--"what you see is what you get"--literal search.  Thanks, all.

Edited November 4, 2018 by TYA

[Λύχνις Δαν]

You could try the . character before the square bracket character. It is used to search for the character immediately following it - hence ".[" should find open left brackets in a text. I should note that the use of wildcards causes a literal search to be changed to an inflected or lemma search.

 

thx

D

[TYA]

You could try the . character before the square bracket character. It is used to search for the character immediately following it - hence ".[" should find open left brackets in a text.

 

Yes, great suggestion.  That works indeed to narrow me down to 192 hits, which is certainly better than where I was before, so thanks much for this.  Attached are a bunch of failed attempts to get closer to finding the [א] or [ב], specifically, using your method.  (Some of these look mangled and nonsensible just because I'm not using a unicode keyboard (I guess that's the reason), and so things get "mangled" or moved around when I input them).

 

I should note that the use of wildcards causes a literal search to be changed to an inflected or lemma search.

 

Yes, I gather that.  I'm sure you understand that I'm requesting that this not be the case.  I want that truly literal search I keep talking about--at least as an option for those like me.

 

Thanks, D.

Edited November 4, 2018 by TYA

[Λύχνις Δαν]

Ok this one is tough. Having poked at it a bit now I can get close with something like this. I have put a screen shot in because that's easier than copying with the non-RTL support of the forum posts.

 

Thx

D

[Λύχνις Δαν]

Yes, I gather that.  I'm sure you understand that I'm requesting that this not be the case.  I want that truly literal search I keep talking about--at least as an option for those like me.

 

I perhaps should make a remark or two here too. Yes I get it and I see the utility of it for sure. I noticed in one of your other posts about that the implication of what you want is to treat spaces in a special way. I noted that a search was done and you got words containing the character you were looking but also other letters when you really wanted words containing just the letters you specified. From one standpoint the search was in fact very much a literal search. It highlighted the characters precisely as and where they were found. I initially thought this was fair enough as a result. I saw both you and Mike objected that there were other characters present in the words. From this I deduce that in fact spaces must be treated as significant and that matching needs to work a bit differently. (I might add I'm not going to this extent explaining what I think you're after for no reason but rather to clarify the exact specification of the search behaviour so that it might be implemented.)

 

And I am saying that spaces are significant because you are actually interested appears to be this:

 

  1. matching a string of characters between whitespace to a specified search string, AND

  2. that that search string must exactly match and account for ALL letters present in the string in the text between the whitespace characters, AND

  3. the search string must support wildcards without switching to another type of search, AND

  4. that if the search string itself contains whitespace it indicates a sequence of words are being sought, in that sequence, and to matched in accordance with 1,2 and 3 above.

 

If this is an accurate statement of what you want then I certainly see the utility in it, and in fact we've discussed before on the forums the value of a straightforward regex support in a similar vein before now, and I think that would still be good. And it is probably implementable, though I don't know Accordance internals and thus how much work would be involved etc. etc. ....

 

  If it's not accurate it would be good to produce an accurate statement of precisely how this should behave. This may seem obvious and tedious but I write software for a living and a lack of clear specification at the outset always leads to unexpected results on someone's part at the end. As I noted above, I thought you had pretty much gotten what you had been asking for until more issues were raised.

 

Thx

D

[TYA]

... you are actually interested... [in] this:

 

  1. matching a string of characters between whitespace to a specified search string, AND

  2. that that search string must exactly match and account for ALL letters present in the string in the text between the whitespace characters, AND

  3. the search string must support wildcards without switching to another type of search, AND

  4. that if the search string itself contains whitespace it indicates a sequence of words are being sought, in that sequence, and to matched in accordance with 1,2 and 3 above.

 

Yes.  And since I don't write software as you do, I very much appreciate your taking the time to draft this out.  So, yes if "whitespace" means a space between words, then yes, this description you gave looks great.

 

Let me mention this: I wouldn't be pressing for (what I'm calling in layman's terms) a "truly literal search" if there was a simple way to negate the prefixes and suffixes from the command line.  (With all due respect, I don't want to get into Construct searches now).  I see that there is a symbol for "negate," but I've tried this numerous times in efforts to negate prefixes from search results.

 

Bottom line, I would really appreciate the ability to find exactly what I want, and only what I want, with "whitespaces" being a dividing factor.

 

(I also want to be able to find a string of words occurring together in a passage, such as shema yisrael, but I don't detect any challenges with that, other than the same challenge when searching a single word--viz., I don't want any characters that I don't specify or make allowance for to be included in the results.

 

Again, if there is a wildcard that can be used right now to quickly, consistently, and predictably exclude / negate prefixes and suffixes from my literal search (from the main command line), then I'm all ears.  That would seem to accomplish what I want, but just from a different angle.  But if such doesn't exist, then please add D.'s wonderful description quoted above.  Thank you.

 

• Super Member
• 
• 4,999 posts

 

Early congratulations on your 5,000th post, D.  Make it count

Edited November 4, 2018 by TYA