You don't mention where the dictionary words come from (a file?), but it sounds like you are trying to handle them all in memory. That could probably be made to work - and very fast - with the appropriate data structures and algorithms.
But, before you go down that road, consider the advantages of a database. Virtually all databases include the ability to create indexes, and index technology is exceedingly advanced. (For decades, database vendors have contended with each other over performance, and one of the surest ways to gain an advantage is to use better/faster indexing schemes.)
For that reason, I'd be inclined to store my words in a database, then utilize the database's blazing retrieval speed to find word matches (and see below, too).
Hash tables are appropriate for small amounts of data. But for large sets of data, they have a drawback: Multiple entries can sometimes generate the same hash value. To move away from that, you have to use hash implementations that generate ever larger hashes.
If you want to "roll your own" lookup functionality, I'd suggest you research some of the following data structure/algorithm topics:
B-Tree (binary tree)
Balanced B-Tree
Red/Black Tree.
There is another potentially fast way to organize words in memory, though it's a little hard to describe: It also involves a "tree" data structure, but each node is a placeholoder for a single character. (The nodes would actually be a little more complex than a single character member.)
At the uppermost level, you have all the characters in your alphabet.
To help you understand the rest, let's use two example words, "ask: and "axe"
At the top level we have an entry for the letter "a".
Beneath the" a" are nodes for "s" and "x".
Beneath "s" is a terminal node (no children) for "k".
Beneath "x" is terminal node for "e"
This is all organized as a kind of linked list.
Your search algorithm then "walks" down the levels in this structure until it finds a terminal node that represents the search word.
Each terminal node would then have either,
a) a member containing the translated word, or
b) a member containing a pointer to the translated word, stored in another list.
The above is an over-simplification of the process, but it should give you some "flavor" for the fascinating world of data structures and algorithms.
If you're still interested in rolling your own, I'd strongly suggest that you also spend some time studying Object Oriented Programming principles, and Design Patterns. The algorithm that would "walk" your tree seeking a word match might, for example, be a candidate for the "visitor" design pattern. And the nodes are candidates for class instances.
All that said, a language cross reference is probably more complex than a bunch of one-to-one equivalences. A given Hebrew word might translate to more than one English word. The reverse is also true. With that, we've identified a well-understood database construct: The many-to-many relationship.
Implementing this will be a lot easier in a database than in your own code.
You'd have three (or four) data tables:
EnglishWords, HebrewWords, and one (or two) "correlation" tables.
This is a case where I'd be very inclined to use a surrogate primary key (autoinc) in my word tables. The correlation table(s) would then contain one pair of entries for each translation match: EnglishWordID and HebrewWordID. Multiple recods in the correlation table would represent translations to multiple words.
The reason for using two correlation tables would be to easily manage false "two way streets" (just because a Hebrew word may translate into multiple English words doesn't necessarily mean that one of those English words is best translated to that particular Hebrew word).
But you could use a single correlation table and avoid the problem by including "direction" flags as columns in the correlation table.
One of the beauties of the correlation table is that, with the addition of one more column (text or blob), you could include information about the nuances of each translation.
One last thought: Since you're coding in VB, consider the Acess database. For an effort like yours, it's more than adequate, and does very fast indexing.
Have fun coding!
VB.Net
Print This
