Your full service technology partner! 
-Collapse +Expand
Search VB.Net Group:

-Collapse +Expand VB.Net To/From
-Collapse +Expand VB.Net Store

Prestwood eMagazine

December Edition
Subscribe now! It's Free!
Enter your email:

   ► MB LobbyVB.Net Language BoardVB.Net Coding Topic   Print This     

Dictionary Hebrew/English

Dictionary Hebrew/English in VB.Net Coding topic (part of our VB.Net Language group).

Quick Search: Dictionary   Hebrew/English   Dictionary Hebrew/English  
-- UNK

I am a beginner in Visual Basic 2005. I have been working on a Hebrew-English dictionary. I used the "If" statement and then the "Select Case" statement but as the dictionary grew bigger it becomes slow "about 15 seconds" looking for the first word. The following words comes very fast when I click "Search". I hope you can give an idea. I read about the Hashtable ..... I don't know
Thank you

 Posted 13 years ago (Thread Starter)
Comment Quote
About khatib_b -Collapse +Expand
Visit Profile
Approved member.
Member subscribes to this thread with a verified email.
Old Account!
If this is your account, sign in to activate web presence data (sign in quarterly to keep active). Alternatively, you can subscribe to our monthly eMag with a valid email address.
Web Presence Hidden.
Once above is taken care of, full Profile content will display including back links, about me, my message, custom Profile html, social networking links, message board signature, company profile, etc.

Post ID #13151, 1 replies
Thread Started 12/3/2008 2:16:48 PM
View Counter=6844
Last Reply Posted 12/5/2008 11:07:31 AM)
Location=-- UNK 
Joined=13 years ago   MB Posts=4  
Most Recent Post
Wes Peterson
Prestwood IT
Prestwood IT office in Citrus Heights, CA

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!

Wes Peterson
Senior Software Engineer
Prestwood IT Solutions

 Posted 13 years ago
Comment Quote
About Wes Peterson -Collapse +Expand
Visit Profile
Approved member.
Member subscribes to this thread with a verified email.
About Wes Peterson

Wes Peterson is a Senior Programmer Analyst with Prestwood IT Solutions where he develops custom Windows software and custom websites using .Net and Delphi. When Wes is not coding for clients, he participates in this online community. Prior to his 10-year love-affair with Delphi, he worked with several other tools and databases. Currently he specializes in VS.Net using C# and VB.Net. To Wes, the .NET revolution is as exciting as the birth of Delphi.

Post ID #13153 (Level 1.1)  Reply to 13151
Thread Started 12/5/2008 11:07:31 AM
Location=Prestwood IT office in Citrus Heights, CA 
Joined=17 years ago   MB Posts=158   KB Posts=163   KB Comments=34   BLOG, Topics=20  

Revive Thread!

Add a comment to revive this old thread and make this archived thread more useful.

Write a Comment...
Full Editor
Sign in...

If you are a member, Sign In. Or, you can Create a Free account now.

Anonymous Post (text-only, no HTML):

Enter your name and security key.

Your Name:
Security key = P147A1
Enter key:
Icon: A Post    Thread    Idea    Important!    Cool    Sad    No    Yes    Includes a Link...   
Thread #13151 Counter
Since 12/3/2008
Go ahead!   Use Us! Call: 916-726-5675  Or visit our new sales site:

©1995-2021 Prestwood IT Solutions.   [Security & Privacy]