Hash tables? - mIRC Discussion Forums

Hi, I wqanna know exactly how useful a hash table is.. I mean what makes it special or useful?

Ps. I want to make one.. I just need to know if it's worth it.. I was thinking of making an ascii one.. I know seems pointless but it seems like it would be an easy start... any help?

Click and Click

In short, a hash table is faster than any form of file access. It's also easier than using variables if you need to search for things and it's better than having a LOT of variables for no reason.

Basic hash table (deck of cards):

Code:

alias MakeDeck {
  hmake Deck 5
  var %Cards = 2,3,4,5,6,7,8,9,10,J,Q,K,A
  var %Suit = H,D,S,C
  var %cnt = 1
  while (%cnt <= 13) {
    var %cnt2 = 1
    while (%cnt2 <= 4) {
      hadd Deck $gettok(%Cards,%cnt,44) $+ $gettok(%Suit,%cnt2,44)
      inc %cnt2
    }
    inc %cnt
  }
}

alias DrawCard {
  var %random.card = $rand(1,$hget(Deck,0).item)
  var %card = $hget(Deck,%random.card).item
  hdel Deck %card
  echo -a You drew this card: %card -- Cards Remaining: $hget(Deck,0).item
}

The nested loops in the makedeck alias just make it easier to add all of the cards in a short amount of code. You could also just do 52 /hadd's or put all of the cards into a single variable and do a single loop through them. This was just faster for me to type out by having 2 loops. It isn't necessary for a hash table.

I use an ini file to store a lot of settings, including the format for the default text of all remote events. It never bothered me, but I went ahead and switched it to hash anyway, and just reload the file at each start up...

Code:

/loadini {
  /var %ini_file = $$1, %hash_output_name = $iif($2,$2,%ini_file)
  echo -s >>Loading $qt(%ini_file) to $qt(%hash_output_name)

  if ($hget(%hash_output_name)) hfree %hash_output_name
  hmake %hash_output_name 10

  /var %outer = $ini(%ini_file,0), %inner, %t1, %t2
  while (%outer > 0) {
    %inner = $ini(%ini_file,%outer,0)
    while (%inner > 0) {
      %t1 = $ini(%ini_file,%outer)
      %t2 = $ini(%ini_file,%outer,%inner)

      hadd %hash_output_name $+(%t1,.,%t2) $eval($readini(%ini_file,n,%t1,%t2),1)

      dec %inner
    }
    dec %outer
  }

}
/settings {
  /var %ini = Misc.ini
  if (!$hget(settings)) loadini %ini settings

  if ($isid) return $iif($1,$hget(settings,$+($1,.,$$2)),%ini)
  /writeini %ini $1 $2 $$3-
  /hadd settings $+($1,.,$2) $3-
}

Why not just load and save the ini file into a hash table using /hload -i and /hsave -i ?

That seems to just load just a single section.

Unless they are settings that get checked fast and a lot or are for critical things like room protections, using hash is a waste of resources in my opinion. Hash is great, it is indeed very fast but shouldn't be overused. Im not speaking about any posted codes here but just in general.

I use hash tables to save information that needs to be checked often and very quickly. Simple settings that may get checked once or twice I use ini or variables, which is ini.

Also, for processing, parsing, evaluating or compiling information hash tables are great.

One advantage of storing the data directly in a file is that, if your system crashes, any data added / changed since the last "hsave" will be lost (as hash tables are stored in RAM).

Note that:
1) If the data is about "settings" (often used, seldom changed), hash is the perfect match: load the data on start, save (update) the data if settings got changed. No need to save the data on exit.

2) A hash-based approach will only speed up the processing of data (as demonstrated above), not the "whole" routine if you change/ add data often and also need to secure the data. To prevent possible data loss, you would have to save the data after every change.

3) "hsave -i" takes a lot more time than a plain "hsave" (At least if the dataset is large).

4) If you need both: fast processing of the data (the advantage of hash) without too much load to secure the data by saving it after every change (the advantage of ini) you can use some kind of tradeoff:

Save tha hash table (if needed, to ini format), but not after every change, but every-so-often. To do this, use either a timer to save it periodicaly; or count the number of changes and save it after x changes. Or you might use something like this:

alias -l eo.htrace.add {
hadd $+(eo.htrace.,$1) $2-3 $replace($4,nick,n,part,p,quit,q,kick,k) $ctime $5
if (200 // $hget($+(eo.htrace.,$1),0).item) { hsave $+(eo.htrace.,$1) $hget(eo.settings,tracefile) }
}

Just an example I picked; It will add the new data to the table, and save the hashtable every time 200 new items had been added (that is: the number of items in the table did increase by 200)

Originally Posted By: DJ_Sol

Unless they are settings that get checked fast and a lot or are for critical things like room protections, using hash is a waste of resources in my opinion. Hash is great, it is indeed very fast but shouldn't be overused. Im not speaking about any posted codes here but just in general.

I use hash tables to save information that needs to be checked often and very quickly. Simple settings that may get checked once or twice I use ini or variables, which is ini.

Also, for processing, parsing, evaluating or compiling information hash tables are great.

Agreed. I know people who use hash tables for all of their script's settings (Invision does as well). That's fine. However, it really isn't worth it for things that are not used often. Hash tables are useful for handling large amounts of data quickly. They also make certain things much easier. But that doesn't mean they are always the best solution.

I wrote an MP3 player script a few years ago that uses filter to search a list file for a particular string. I recently tried using a hash table instead, but found that the filter search was much faster. In this case it's read-only, but it showed me that for large applications such as huge MP3 lists (40,000+ files), using hash is slower. I reverted back to using filter and my script screams. Just an observation.

Are you sure you are using the hashes properly? The $hfind identifier should be MUCH faster than the /filter command. You shouldn't be looping through the hash with $hget

-genius_at_work