Thursday, November 29, 2018

10 Ways to Search for a Word in Tanach

Here's a shot of the Options Page in the toraware website, after making the choice to "Find a Word" on its Home Page.

Look how many ways you can search for a word in Tanach at One subset of options has two options while the other subset offers 5 options, so altogether you have 10 combinations to search with. Not that you'd use them all, but they're there in case you need them.

Wednesday, November 21, 2018

A Speedy Way to Explore Torah

How often do you want to know, on a moment's notice, where a word, or verb, first appears in Torah? Or, is there such a name found in Torah at all? Or how many times does a phrase or word exist in all of Torah or Tanach?

Sure you can do a search and find your answer on the internet, but that’s still a rather burdensome task. That is, at best, you can still find that word, phrase or verb after a few minutes of surfing and clicking.

There are plenty of sites with such facilities to navigate through, but you’ll still spend way too long – so you’d never even try to satisfy your momentary curiosity because the delay isn’t worth it. Even a few minutes when your doing something else, like cooking or eating, can be too troublesome so you let your spontaneous curiosity waste away.

But that’s because you don’t know of the Toraware app that gives you rather immediately in the palm of your hand the answer to your sudden urge to know or explore or validate.

In two clicks, the first to open the app from its Home Icon, and the second to click on “Find a Word” or on “Find a Phrase”, and you’re ready to type in the letters formed in your mind, and a 3rd click then brings you immediate visual results. Three clicks is all it takes in most cases.

With the use of only two buttons, and typing the word you're thinking of, in a matter of seconds, you get immediate results. Each click on the “GO” button can scan through all of Tanach in a second, or two seconds, and display the list of results.

By default, that’s the way it works. But each search method (and there are 10) also sports a different set of options, so you can, if you want, come up with unique ways to find what you’re looking for.

For instance: Suppose you want to know the number of times Moshe is mentioned in Torah.

(As a side note, names are easy to catch in Hebrew text in that they always are either mentioned by themselves, with no extra attached letters, or the attached letters always are placed in front of the name. That makes it easy to program a search that focuses on the suffixes of words.)

So you use the method “Find a Word” (1st click). On the next page, the Options Page, the best option to choose would be: “ENDS with my letters” (2nd click). Now type in the 3 letters משה, and hit the “Go” button (3rd click). Every single word in Torah (the default search range is already set from בראשית to זאת הברכה) that has as its last 3 letters the letters you typed in (“משה”) immediately appears in a list before you (the Results Page). The number of such “hits” is 721.

Now, not all these hits are good hits. For example, many in the list include the irrelevant word “חמשה”, because this word too ends in those 3 letters. So you have to be clever with use of this tool, to devise a way to narrow in on your answer.

So let’s now search how many times the letters “ חמשה” are found.  Then we can subtract this number from 721. So you hit the “Back” button; The options you selected previously remain as is, so all you do now is type in the word “חמשה” and press “Go”. You get 72 hits. So now we know that from the 721 results we have 72 to take away, leaving now 649 alleged times Moshe is mentioned. You’re left with all significant hits, such as:
etc., all of which are mentions of משה.

Besides being clever, however, you also have to be lucky, lucky to have learned Torah. I learned this the hard way, unaware of two such mentions in Torah, by once publishing a faulty blog post; I had missed these two words. But I now know of the two times these same 3 letters have a different meaning, so the real answer is 647. There are two false positives among the results list, which whittles it down from 721 to 649, and then to 647. In Shmot 12:4 it means “less than one calf”, and in Devarim 15: 2 it means “creditor”. Of course these two words are pronounced differently in Torah but the Toraware tool doesn't inspect pronunciations.

This search can be further explored, if the range is set to all of Tanach (just extend the Range on the opening Home Page, which defaults to the Torah limits). Now the 3-letter search yields 920 hits. Let’s subtract how many times the insignificant ending “חמשה” is found, That’s 150. Thus we get 920 – 150 = 770. Don’t forget two of these we know are false positives, so our final total becomes 768! Let’s not forget that in Tanach there may be other words besides חמשה that might throw us off, but personally I doubt it.

P.S. I wrote about this previously, over here, although back then the Toraware tool hadn’t been as useful as it has become presently, in its 54th version.

P.S. Ever wonder how many times Jerusalem is expressly mentioned in Torah, or in Tanach? I discuss that here.

Sunday, November 18, 2018

Found a Bug in the New Options of the "Find a Word" Method

Suppose you seek the letters בח, and the program comes across the word במזבח.

My logic was: If the Bais yields a hit, as it does, on the 1st Bais in במזבח,
then I'll search for the letter ח next.

If these letters are grouped together, then the "BOUND" qualification is true. But here, because the first ב and the ח are not grouped together, I get a false result -- because there's another ב in the word that does have a ח bound to it, which I fail to detect.

I'm back at the drawing board and must resort to deploying the 49th version until I resolve this bug.

UPDATE: (11/20/18):
Redid the code (more modular and less complicated) and now, thank G-d, it's flawless. Reinstalled as Version 54.

The Options Page of the "Find a Word" method is now, again, like this:

Tuesday, October 23, 2018

Some Torah Numerology

Here's an interesting numerlogy: If you begin reading the 1st chapter of Genesis (in the original
Hebrew language) and find the first T (ת in Hebrew). The first occurrence of this letter is the last letter of the very first word (בראשית). Then skip the next 49 letters to read the 50th letter as vav (ו). You continue this way two more times, every 50th letter, to obtain the word Torah, “תורה,” the Hebrew word for the first five books of the Bible (the Pentateuch).

(You'll find too, that from that 1st Tav in Genesis, were you to skip therefrom over 132 letters,  i.e, every 133rd letter therefrom, you'd also arrive at the same word, Torah. I only checked up to the skip value of 250; So there may well be more such, but larger, equidistant-skip findings.)

Monday, September 3, 2018

Yet Another Option for FIND A WORD Method

The "Find a Word" method now has yet another new option to help you find the word you seek. (With all these options you now have available, you'd be hard-pressed not finding the word you want.)

This new option is called "my letters in SEQUENCE". It means it'll find all words that contain your input string of letters in sequence, i.e., back to back. (The radiobutton's label should read
"my letters INCLUDED in SEQUENCE"
but I was short on space, so I compromised on the wording.)

For example, if you wish to find a word containing the letters "ראש" in sequence within a word, then the word "בראשית" would show up (given, of course, that you set your Search Range to include Parshah בראשית within your scope.

Now at version 52.

(Not that all combinations are of equal significance, but each new option actually multiplies the number of combinations available. Having added one to the lower set of options, of which there now are 5, along with the two options in the upper set, now gives the user 10 combinations of options and corresponding results.)

Tuesday, August 28, 2018

New Option for "Find a Word" Method

Often, in looking up a Hebrew word in Tanach, the word may have prefixed letters attached to it because in Hebrew these additional letters act as additional words, unlike in English where extra words are used rather than elongating the word with prefixed letters.

For example, "to Moses", "and Moses", "like Moses", "with Moses", "via Moses", "at Moses", "and by Moses", etc. -- all these terms comprise only one word in Hebrew word. Hebrew accomplishes this simply by affixing a letter or two in front of the word, extending the length of the word by one or two or more letters.

To ignore these prefix letters for your search, which you often consider insignificant, it is now possible to use "Find a Word" using a new option, now introduced, namely, letting you specify "My ENDING Letters".  Insignificant prefix letters can thus be ignored to find your word.

So, in this example, if you were just looking for words that contain Moses, you can specify "משה", use the option "My ENDING Letters", and words ending with your 3-letter word will show up without having to know beforehand exactly what insignificant letters begin the word.

With this option you'll get hits such as:

Now at version 51.

Thursday, June 14, 2018

Hit-Limit Reminder Installed

Version 50 of Toraware now sports at the end of the Results List a line of text in case the hit-limit count was encountered. This would now remind a user there might, in fact, be more results forthcoming were he to just increase his hit-limit count. Without this text-line-reminder, the user may well not realize he came to the end of the list prematurely.

Now at version 50.

Saturday, March 24, 2018

How Many Times is "JERUSALEM" Mentioned in Tanach?

The answer may surprise you. Expressly, never in Torah. That's not so surprising since the Jews entered Eretz Yisrael in 2488, whereas Torah chronicles what happened during the prior 40 years in the desert.

In Nach, however, it appears no less than 669 times! Imagine that.
Options Page:

Results Page:


Wednesday, March 21, 2018

New Option for "Find a Word" Method

The Find a Word method now has a new option, which allows the user to specify the leading letters of a word for his word search.

In effect, this method now has 6 choices for ways to search out a word.

This deployment constitutes version 50.

Wednesday, January 17, 2018

Methods Roshei & Sofei Possukim - Corrected

Thanks to a friendly user of my website, I came upon a bug in two methods I thought were simple pieces of code, but in fact they needed correction. This is the 2nd time she found a bug! Thank you again Zahava P.!!

Ever since I expanded the database, from just Torah to now include the entire Tanach, a variety of issues suddenly arose that I was made aware of only later.

Previous methods regarded the Torah database to be one big book, where Parsha borders were ignored. If results spanned from one Parsha into another another, that was okay.

But with the expanded Tanach as my new database, some methods or option (gematria's "successive possukim") no longer make sense. Now, borders between books became significant.

For example, in a gematria search with the “successive possukim” option selected, it makes no sense if the gematria result began in one book and the rest of the gematria was found in the next. To illustrate, if the last verse in Torah comprised one part of the gematria, and the rest of the gematria was found in verses of the next book, Yehoshua, this "hit" would make little sense.

(My screw-up came up because I had to allow for spanning to occur for the books Shmuel A & B, Divrei Hayomim A & B, Ezra & Nehemia, and Melachim A & B, and this code was incorrect.)

This same problem exists in methods such as “Equidistant Letter Sequence”, “Sofei Possukim” and "Roshei Possukim". Because in each of these methods, the results found might span from one book across into the next, and such spanned results have no good purpose.

I coded my way out of this “new” problem in 3 situations but I could not do so with the “Equidistant Letter Sequence” method. This code as it is is already quite complex so I just couldn't. Instead, I simply put the burden on the user, forcing the user to specify proper borders for his search region. The "Range" parameter can easily be set right by the user on the Home Page.

I'm sorry I could not code my way out of the “Equidistant Letter Sequence” method and had to resort to issuance of an error to bypass this inability. It's awkward because the same error ought to pop up for “Sofei Possukim” and "Roshei Possukim", because these too make no sense were results to span across separate books. But here this situation can no longer happen because I code it so that spanning will not take place.

Here's the error that shows for the “Equidistant Letter Sequence” method when the range parameters must first be properly specified:

(With this correction, and with what I did to streamline "Find a Phrase", I believe the entire program is now 100% well and accurate, ב׳׳ה.)

Now at version 48.

Monday, December 11, 2017

"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.

Monday, November 13, 2017

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.

Sunday, October 15, 2017

The Simple Storyboard Underlying

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.

Sunday, October 1, 2017

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.

Monday, July 10, 2017

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, 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.)