mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Mar 2008
Posts: 44
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Mar 2008
Posts: 44
Hi,
The problem am havng in the below script is that from %i = 4 onwards, the line $hget(search.results,%i).item keeps returning sresult.3 when it should return sresult.4, sresult.5 etc.
I have echoed the value of %i, & so for example for %i = 4 it should return sresult.4. even the mirc echo line in these cases says "* Added item 'sresult.4' to hash table 'search.results'" , but $hget(search.results,%i).item still returns sresult.3

THankyou
---------------

Code:
if (hget(search.results)) hfree -s search.results | echo 12 -a freeeeeedd!

  var %stok = 1
  var  %i = 1
  var %etok = %stok + %s.chunksize

  while (%stok < %total.search.toks) {
    echo 12 -a - stok = %stok , etok = %etok
    hadd -s search.results sresult. $+ %i $getbintok(&search.results,$+(%stok,-,%etok),44)
    echo 07 -a * i = %i , $hget(search.results,%i).item
    ; echo 13 -a results :  $hget(search.results,$+(sresult.,%i))
    var %stok = %etok
    var %etok = %stok + %s.chunksize
    inc %i
    echo 04 -a -- stok = %stok , total.toks = %total.search.toks
  }

halt

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Realize that you're using a hashtable here. Hashtables are (classically) unordered data structures. mIRC's implementation is no different. This means that $hget(tabname,N) does not guarantee order-- you will not always get the Nth inserted item. You will get whatever item is hashed at index N.

To explain your results, I imagine mIRC is probably hashing sresult.4, 5, 6, etc. in front of sresult.3 and pushing result.3 to the end of the list, continually making it the last item in your hashtable. $hget(tabname, %i).item will therefore always be sresult.3 when %i is the last index. Again, this depends on the data set you're using and may change drastically if you changed your item names from "sresult" to "results". It may even change when you get to sresult.7 or higher (you don't need to confirm if it does or doesn't, this is just hypothetical).

Long story short: don't access items by their index; even the help file warns against this. It's both inefficient and defeats the purpose of using hash tables. Besides-- you were smart enough to embed an index in the item name, so you can already directly access items by your own logical index: $hget(search.results,$+(sresult.,%i))


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Mar 2008
Posts: 44
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Mar 2008
Posts: 44
hi,
argv0 wrote. . .
Quote:
This means that $hget(tabname,N) does not guarantee order-- you will not always get the Nth inserted item. You will get whatever item is hashed at index N.

I've been stuck on this a couple of days & that was a Huge help, I wasn't aware of this.. & had asked around in a couple of places but no one mentioned that.
I had only read about a certain access being inefficient in the help file but i mistakenly thought it referred to just $hget().data since it was mentioned after that in the help file.

Thanks again for the explanation.
-


Joined: Mar 2008
Posts: 44
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Mar 2008
Posts: 44
just one small thing, what about
Code:
$hget(search.results,0).item
to get the total number of entries in the hash table, that's fine to use right ? (or is there a better way of doing this)

Thanks.

Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
That's what should be used yes smile


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
The .item suffix is not needed to get the total size, by the way.

edit: this is wrong. .item or .data are in fact needed.

Last edited by argv0; 17/05/09 10:20 PM.

- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
Joined: Mar 2008
Posts: 44
N
Ameglian cow
OP Offline
Ameglian cow
N
Joined: Mar 2008
Posts: 44
thankies wink

Joined: Aug 2004
Posts: 7,252
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
Using $hget(<table>,0) will return the size of the table, as specified in the /hmake command.
However, $hget(<table>,0).item will return the number of items in the table.
The size of the table and the number of items in the table are, rarely, the same.

Joined: Nov 2006
Posts: 1,559
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Nov 2006
Posts: 1,559
Erm, "total number of items" requires either the .item or the .data property, and "size of table" the .size property, doesn't it?

Code:
//hmake x 7 | hadd x a | hadd x b c | echo -ag no prop: $hget(x,0) item: $hget(x,0).item data: $hget(x,0).data size: $hget(x).size | hfree x
returns: "no prop: item: 2 data: 2 size: 7"

Joined: Aug 2004
Posts: 7,252
R
Hoopy frood
Offline
Hoopy frood
R
Joined: Aug 2004
Posts: 7,252
As you have shown, the size property return the size of the table, but omitting the property will return the size of the table as specified in the /hmake statement.

Thus, I'm unsure as to how one would test this, the .size property might return the larger of the actual table size or the size specified in the /hmake command.

Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
I think you misinterpreted his results.

omitting the property does not return the size of the table specified by the hmake statement. Only the .size property returns this value as written in the help file.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"

Link Copied to Clipboard