Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 749
  • Last Modified:

Quadratic Probing

I'm trying to implement quadratic probing to resolve hash table collisions.  Usually I use a linked-list method, but I want to try out quadratic probing.

My basic "get" function uses a loop like:

            for (unsigned n = 1; table_space[idx] != EMPTY; ++n) {
                  if (memcmp( table_space[idx].key, key, strlen(key)) == 0)
                        return table_space[idx].value;
                  idx += ( (n+1)*(n+1) ) - (n*n);
                  if (idx >= Capacity) idx %= Capacity;
            }

I'm not sure if I'm implementing the quadratic function properly.  If the idx value exceeds the capacity of the table, I reset it to the beginning of the table with a modulo/assignment.  However, I've seen some implementations which use the hash value itself for the quadratic function, rather than the table index.  Is there any difference, and is the above implementation adequate?
0
chsalvia
Asked:
chsalvia
  • 3
  • 2
  • 2
2 Solutions
 
Kent OlsenData Warehouse Architect / DBACommented:

Hi chsalvia,

I'm assuming that idx is initialized prior to the for(;;) statement?

For my money, I like the linked-list approach for dealing with overflow.  It's easier to implement and means that a slightly less than optimal hash algorithm still works reasonably well.

What you're attempting requires a dead-on algorithm or quite a bit of extra space as an overflow record is moved to another location in the primary pages, often resulting in the misplacement of additional data.

But your code looks fine.

Kent
0
 
chsalviaAuthor Commented:
>>I'm assuming that idx is initialized prior to the for(;;) statement?

Yes.

>>For my money, I like the linked-list approach for dealing with overflow.  It's easier to implement and means that a slightly less >>than optimal hash algorithm still works reasonably well.

I think so too.  It also lets you fill up the table without too much performance degradation.

I've been experimenting with ways to get fast hash table performance with minimal memory allocation and the option for variable length records.  In C++, hash tables usually allocate new objects on every insert, which involves a lot of sporadic memory allocation.  An object is allocated to the heap, then its constructor is called, and maybe the object allocates some storage for some internal variables as well.  

With C, I was thinking I could get a pretty fast hash table which would allow variable length records, by doing something like this:  Making a table that is just an array of integers.  Each integer would store the offset of a record stored in a larger heap space.  The problem is that this requires two resize operations - one for the table, and one for the storage heap.  

But I thought it would be a nice way to store variable length strings, or any kind of data, and be able to have a hash index to look it up quickly.  Plus, barring the resize, there would be no memory allocation on inserts - just a quick assignment to the proper index, and a memcpy for the storage heap.

I was looking into quadratic probing because if I used a linked-list, the hash table would need to be more than just a simple array of integers - it would need to be an array of integers and next pointers.  
0
 
Kent OlsenData Warehouse Architect / DBACommented:

>> if I used a linked-list, the hash table would need to be more than just a simple array of integers

All kinds of hybrid solutions are out there.

typedef struct
{
   char Key[20];   // or whatever
   int    Offset;     // Index into the list
} key_t;

typedef struct
{
  char Key[10];
//  rest of data
} mystruct_t;

typedef struct
{
  key_t   key[20];
  page_t *overflow;
  char    pad[x];
} page_t;


Use the definitions above to manage the keys, then keep the actual data as separate structs.  The hash table winds up being relatively small with very fast access to keys and/or data.


Kent
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
ozoCommented:
idx += ( (n+1)*(n+1) ) - (n*n);
That seems strange way to write
 idx += 2*n + 1;
0
 
Kent OlsenData Warehouse Architect / DBACommented:
Hi ozo,

Yeah, and

   if (idx >= Capacity) idx %= Capacity

is probably better written as

   idx %= Capacity;


But the logic seems to be the initial issue.
Kent
0
 
ozoCommented:
If the table is full, you will loop forever
0
 
chsalviaAuthor Commented:
>>idx += ( (n+1)*(n+1) ) - (n*n);
>>That seems strange way to write
>>idx += 2*n + 1;

Yes - that's a lot simpler.  

>> If the table is full, you will loop forever

There is a resize function that is triggered when the number of records reaches a certain load factor.

>>Yeah, and
>>   if (idx >= Capacity) idx %= Capacity
>>is probably better written as
>>  idx %= Capacity;

Yeah - the if statement is redundant there.  I suppose the whole thing could be expressed in one line like:

idx = (idx + 2*n + 1) % Capacity;
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 3
  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now