Forums Feature Suggestions Iterate through hashtable collection with wildcard

I think it would be convenient to be able to access hash table names with the use of a wildcard, similar to what you can do with sockets, like $sock(<wildcarded string>,N).

Of course, because $hget already has another meaning in that syntax, another syntax would have to be used, perhaps $hget(<wildcarded string>,N).col or whatever Khaled may find appropriate.

This suggestion is handy for example when you have hash tables from a certain collection that belong together. Fex:

prefix_htb_<value>

With this new feature, I'd be able to loop through all hash tables starting with prefix_htb_*, without having to loop through all hash tables loaded, with $hget(<index>) and do an iswm check, as is currently the only way to go.

I'd like a bigger Hash table limit.

e.g. /hmake hashtable 65536

instead of the limit of /hmake hashtable 10000.


(I think I covered this before somewhere ...)

Since you can add as many items as your RAM allows, it's not so important. That limit isn't really a limit, you can add more items than 10x the slot size that you specified with hmake. But if you really wanna add 650000+ items, then a hash table isn't suited for that, a database should be used instead. Just know that you can, regardless of the slot size.

This is completely unrelated to my request btw o.O...

/hmake test 65536



The only way you can breach 10000 is by /hadd (on the fact that there are 10000 items within the hash table already)

What you just said made no sence.

if you go /hmake test 10000 it still has ZERO items, thats just a number to uses for the initial number of slots (i think that means differing returnable hash values).

As i understand it, its like issuing 10,000 numbers from 1 to 10,000 out, then you add an item called "BLAHHO" and you hash "blahho" into a number it might be 3,478, so go to box 3478, if its empty put BLAHO and its data in the box, repeat this for each item added. If u add lets say item "CATTAILS" and it hashes to 3,478 you go to that box, theres already something in it, so find the next free box after 10,000, lets say its 10,001, and put CATTAILS and its data in there, now go back to box 3,478 and on its lid write down 10,001, later you come to add item "FLEAS" and it also hashs to 3,478 so go to box 3,478 its full, so find a free box after 10,000 , and u find 10,092 is free so put it and its data in there, go back to box 3,478 and well damn somethings already written on the lid, so get that number 10,001 go to that box, that lids clear so write 10,092 on it.

So now if u go to look up "BLAHO" or "CATTAILS" or "FLEAS" you get 3,478, you now only have to check box 3,478 if its not the one u want follow the number on the lid to 10,001 and if thats not it follow that one to 10,092, simply 3 accesses, rather than looking through 10,000+

*of course i simplified it alot, like didnt mention how it would check if the items existed or not already, but im sure u could see that logic.

Assuming you had 2,000,000 items on average there would be a linked list of boxes to go through 200 long to find any one item, 200 accesses, if u didnt speciifcy a size the defualt 100 is used and the linked list would be 20,000 long each, in either case it appears accessing these items is rocketingly quick.
However the time to load the table increased considerably (10 fold) between having a HMAKE 10000 and only a HMAKE 100 (100 was x10 the load time)

Agreed. I wish the scripting language was more consistent in things like this. $timer should also allow wildcards.

Not to take away from this, but there might be some problems with dealing with what is what, since omg*wildcards?allowed*in*hashtable?names is a valid hashtable name.

And before anyone asks, NO i have never used them like that, in fact i replaced the * and ? (and &) from some i needed to make that had them in with &2A &3F &26

This "issue" is not something to take into account. $var and $sock allow for the proposed functionality, and both may also contain wildcards in the actual name. People who choose to include wildcards in their name shouldn't be surprised that when trying to iterate through a collection based on a wildcard, it may cause unrequired effects. That's their design choice, and their problem.

It wouldn't form any sort of problem, since some new syntax should be used so that it is clear you are trying to use a wildcarded string, not an actual name. A .col property for example. This way, only when .col is used, is the htb name seen as a wildcard, whereas in all its normal uses it remains as it is, being the name is treated as plaintext, even if it contains wildcards. That means, those who don't use wildcards in their hash table name, will be able to use it just fine, and those who do put wildcards in their hash table name shouldn't complain, as they didn't think things through.

oh come on what about a cool hashtable name like *&!@^#*&^!@#&@^#*!&@

No actually my reply was to ask what the .col stood for ? .collection ?

Even if your table was named *&!@^#*&^!@#&@^#*!&@ the very same wildcard would match it, so I don't really think this is an issue unless you use tables like *&!@^#a*&^!@#&@^#*!&@ or *&!@^#b*&^!@#&@^#*!&@ as well as *&!@^#*&^!@#&@^#*!&@

take no offence
but you guys are nutz !!!
:P

You just figured that out?