"Find a Phrase" -- A Powerful Tool in its Own Right

This (46th) version of Toraware’s search program sports a new “Find a Phrase” rendition. The earlier version had some problems. Now the code is extremely streamlined, bound to yield quick, accurate results.

This method searches words in the same order as the user enters them (separated by spaces), thus the use of the word “phrase”.

Unlike “Find a Word”, where there’s an option to match the letters in any order, in “phrase” searching your words are assumed to be in their natural (same) order, as well as the letters you stipulate. The "Find a Word" method searches for one word only. The "Find a Phrase" method seeks multiple words in a verse.

“Find a Phrase” options offers 4 ways to search.

1) You can seek words with only part of the words you’re seeking. E.g., you can search צם, and the word in the verse מצרים would register as a “hit” - under the "INCLUDE my letters" option.

2) You can specify the words you want should be exactly as keyed in. This is the "ONLY my letters" option.

3) & 4) You can also specify in either of the above searches that you want your words in adjacent sequence ("Consecutive words" option); Or you can opt for "Not necessarily", where the words could be found with other words intervening, i.e., they'll appear in the verse, but not consecutively.

As always -- read the title of the Results Page to remind you which options you specified; You needn't go back to the Options Page to see.

Suppose you want to find where in Tanach we have 8 words in a possuk with the following letters in them, respectively:
א ב ג ד ה ו ז ח

You'd get the results shown on the right (click image to enlarge it).

Note: How you spell your own words for the search is important because you do NOT need to include all letters of the word. For example, often the letter “vov”, the grammatical letter with the sound “Oh” (or “oy” according to others) is absent, so it’s best to exclude it. E.g., if you search for יעקוב you'll miss יעקב, but if you search for  יעקב, you'll get them all. As long as the main letters of the root are in the word, this search can find the phrase.

This fix I believe renders the search engine just as I initially conceived it to work fine. Perhaps now, if free time avails itself, I'll try convert it to a mobile app. As you can see from my compact design, button placements and functionality, I had that very goal in mind from the very beginning. Although for now I'm real happy for this website version. It's a good little tool that I myself often use.

Now at version 46.

Awkward Results May Appear (now fixed)

As I expanded the database from just Torah to include the rest of Tanach, a logical dissonance erupted in my code unnoticed until now.

Of all methods available on Home Page, a few new methods added later may yield some results, or matches, that make little sense depending on the Range parameters the user can set on Home Page.

Let’s say the user sets his Range so that he searches the entire Tanach. In other words, he sets the Start of his Range to “Bereishis” and the End of the Range to “Divrei Hayomim B”.

Now suppose he chooses the method of “Roshei Possukim”. Suppose too the last verse in one book - together with the first verse of the next book - score a match (a “hit”). Were these verses within the bounds of Torah, i.e., anywhere between the 1st and last chumash-parsha inclusive, then that’s fine. All results would make sense.

But suppose the last verse in Joshua - together with the “next” verse, which would be the first verse in the book “Shoftim” that I had juxtaposed to the Joshua book, comprise a match? What good would that result be? None from a logical standpoint. As long as juxtaposed books comprise a unit, as do the 5 Chumashim, or the pair of books Shmuel A and B (or also Melachim A and B and Divrei Hayomim A and B), then results than span across these books still can be considered worthy.

But searching say, Joshua and Shoftim, or any other juxtaposed books that are separate entities, shouldn’t show such results in the first place.

Methods like “Find a word”, “Find a Phrase” or “Bookends” still apply as before, and make full sense - no matter what range is set by the user.

But methods such as “Gematria” - run under the specific option of “successive possukim” (see image below), where multiple verses comprise the match, spanning separate books makes no sense. Similarly, the methods “Equidistant Letter Sequence”, “Roshei Possukim” and “Sofei Possukim”, where more than one possuk make up the result, spanning books ought to be prevented.

Well, I haven’t yet figured how to modify the code.

Here's an example of such an awkward match or "hit" (Options Page and Results Page are shown):

Notice the result is comprised of two verses whose gematria add up to 3828. These are the last verse in Tehillim  plus the next verse, which is the first verse in Yeshayahu! This is an awkward "hit", to be sure, and completely insignificant.

UPDATE: 1/17/18

Glad to say these changes have been made - to remove awkward results. My post dated 1/17/18 (link) explains it all.

The Simple Storyboard Underlying Toraware.com

Toraware's website has a simple paradigm. It has only 3 pages. Yet this minimal set of pages runs many powerful searches with instant results. It's a compact, streamlined multi-tool for searching Tanach (a Jewish "Swiss army knife").

The Home Page offers a list of methods to search by. There you can change the range of text to search. And there you can set the number of "hits" you want to display.

Page 2 is the Options Page. Because each category has its own options, the user can here override the default settings. Here too is where the user's input is taken.

Page 3, the Results Page, shows all the "hits" for the method and options the user chose. The title on this page summarizes the method and options chosen, so the user need not remember them or go back to see what they were.

It works like, and appears like, a mobile app in a smartphone.
From page 2 the user can return to page 1.
From page 3 the user can return to page 2.

 METHODS                   OPTIONS                    RESULTS
________ <==>  ________ <==>  ________   
  Home                 Options              Results
   Page                    Page                  Page


Page 1) A choice of methods to query by; And two global options.
Page 2) Options available for that chosen method. Here the user enters his input.
Page 3) Shows matching results, each hit detailed in a list.

A Little "Bug" Detected and Fixed

The result-page to the left shows the title incorrectly rendering (after using the search method of "possuk's gematria factors"). Therein, instead of displaying the sum of the letter input correctly, javascript placed an "NaN" there instead.

This now stands corrected.

Navigational Buttons Repositioned

The Results Page (which displays the “hit list”) presented a problem when that list contained many hits, because scrolling down to view more hits hid the Back button that was situated near the top of the browser’s window.

In that case, new users would probably hit the browser's back button if they wished to return to Home Page or to the Options Page -- instead of scrolling back up using my "Back button"! Using the browser's Back icon expels the user from toraware.com, besides losing the user's place and the options he/she selected.

Because this site was designed to eventually also be used also on a mobile device, it was created with a simple two-button navigational system, operable only with the two buttons the program itself provides dynamically.

So how was the problem solved? By not requiring the user to scroll up to the top of the list to bring the button into view. The Back button now is always in view. No more scrolling up to see it is necessary.

One swift, simple change fixed the problem. Two or 3 lines of CSS3 code did the trick.  The buttons are now "anchored” to the bottom of the browser's window, always present. Hopefully this will help prevent the user from hitting the browser's navigational buttons.

   ~ ~ ~ ~

Another minor change was introduced as well: The "geometric possukim" options now have a 3rd option, where both square and triangular features are shared by the same possuk. (It turns out this combination always yields only possukim that are triangular of 8 and square by 6.)

New Kri/Ksiv Option Delayed

Tanach, after all, comes in two versions. So far, the only database available is the Ksiv version.

Toraware wants to provide the option to also search the Kri database. I would have added this to the Home Page as the 3rd global parameter, in addition to Range and HitLimit parameters (see red arrow).

But I ran into technical problems. How do I dynamically modify an external file's reference? The additional database will now sit in reserve until I figure this out. Apparently the use of "jQuery" will resolve this obstacle, but this will take time to learn, if I get to it. I also don't know if I should use two SCRIPT tags to require initial download of both files.

But my failure turned out to be a blessing in disguise. During creation of the new Kri database, I found several mistakes I had made in the original Ksiv database. The amount of corrections was significant. (Wherever more than one kri-ksiv instance occurred in the same possuk, there I erred in my original editing.)
~~~~~
The Home Page display meanwhile also got a slight facelift, in my attempt to present the Search Range as more intuitive to the first-time user.

Known Potential Errors Not Yet Adjusted For

There are 6 quirks of Tanach I have not yet managed to accommodate in my search program. There are the 5 quirks of the "piska" being in the middle of a possuk, and one quirk where a "sofit" letter appears in the middle of the word, instead of at its end.

There are a few verses in Torah configured peculiarly because each verse actually consists of two verses combined into one. The two parts together make up the whole verse, even though in concept the two verses could be considered logically distinct from the other, but for some reason this is how it is. (The asterisked verse in the illustration shows such an instance.)

This notation, that “there-should-have-been-a-break-between-verses-here” (between component verses), is called a “piska”. In Torah, the piska physically manifests as spatial breaks in written scripture, either as a {פ} or as a {ס}.

There are 3 piskas in Torah, and 2 more in Yehoshua. Here are their locations:

1) beraishis 35:22
2) bamidbar 26:1
3) devarim 2:8
4) yehoshua 8:24
5) yehoshua 4:1

These grammatical quirks result in two component logical segments physically occupying one verse.

When I first designed my database, it never occurred to me two component verses could be "squeezed into" one physical verse.

How woud this effect results? Suppose, for example, you seek a gematria where the result will be a whole possuk. Were any of the piska component verses also hold this value -- I’d miss it -- because I don’t test component verses. I deal only with the whole physical verse.

Ideally component verses should also be subject to individual examination.  But it’s too late to patch this up now to accommodate these possible extra contributions to search results. Even now I wouldn’t know how to design my database without overloading the program with a lot of extra code. It would horribly slow things down to check every verse -- when only 5 verses in all of Tanach have this quirk.

To this minor degree (and to the extent where these may be relevant), my search results would suffer from less than the full set of possible results.

The 6th quirk that might render a wrong result is in Yeshayahu, chapter 9, possuk 6. The first word (לםרבה) has its 2nd letter as a "mem sofit" instead of being written as למרבה.

In the meantime, rather than change the configuration of my entire database as I originally conceived it, as well as the necessary changes in code that would entail, I'd rather just "live with" this source of potential error.

New Method of Multi-Word Search Introduced

Rather than complicate the Find a Word method by asking how many words in a verse are being sought, I introduced the new search method Find a Phrase as a separate multi-word method. Nor do I plan to combine them in the future because each method comes with different options.

Unlike the single-word search, this multi-word search has no "reverse order" or "any order" option.

The only proviso for word entry for this new method is to separate the user's words with a space between them. This proviso is always on display just above the user-entry field.

Finally, as of yet there is an important caveat as far as the matched results that are found is concerned, and this caveat is explained in the trailing Post Script.

---------------------------------------------------

  
Example 1:
I read in the Rebbe's Maamarim that "יציאת מצרים" is mentioned in Torah 50 times (the same count as the 50 "שערי בינה"). So how would I locate these 50 mentions? This new method provides a way. I can type in two words; The 1st will be letters from the root verb "to go out", namely, "צא"; And the 2nd word will be the name "מצרים". As follows:
















This set of options results in 82 hits. Probably most of the 50 hits show up in the result list this way, although at least 32 will have to be eliminated. Below you see the last 8 hits. Of these, #77 is a false hit and would not count. The others here seem to be hits.

Below, you see the first 8 hits of the above search. The first 5 hits also can be eliminated.

Notice I set the 2nd option to "not consecutive". That's because the verb and its object, the name, needn't be adjacent words. Other words can be wedged in between the verb and the name, as is evident in #8.

But mention of "יציאת מצרים" can also occur where the name precedes the verb. Using only the option set we used above, as well as the user's entry, would certainly miss detection of this less common form of speech.

So below is the other thing you can do to catch more of the 50 mentions this way. Note here the user's two-word entry is reversed from what it was before! This will yield results the above search would miss. Of 7 hits,  #6 (see below) probably also qualifies as one of the 50 mentions.























---------------------------------------------------


Example 2:
Suppose you want to locate “יעקב יעקב”, where or if it exists anywhere in Tanach.

Just type in both words, choose among 2 options (= 4 scenarios), and hit GO.



The above set of options and user entry yield the single hit:

---------------------------------------------------
Now at version 42.

P.S. 
This method may miss hits if more than one hit in the same possuk is available. Only the first hit in that possuk will be reported while the rest, if they exist, will go unreported. This simplifies the code immensely. Although this method can be tweaked to include all matches, I leave this code in place, as is (at least for now) because it is still a powerful search method.

toraware.com Home Page Adds Hebrew Markings

Home page now sports Hebrew too, a new “facial”:

_________________________________