mIRC Homepage
Posted By: Skip /hord (hash order) - 01/05/03 03:25 AM
While the idea of sorting hash tables has been brought up (and dismissed?) many times, I feel mIRC lacks some much needed flexibility in this area.

Hash order would not (necessarily) use the item or data to sort the order in which data is retrieved, instead, an 'index' has to be maintained by the user/script with the /hord command:

/hord <name> <item> [data]

Obviously this looks pretty much like the /hadd command, the user adds an 'order' to an item (or removes it), and the $hfind() identifier is extended to become:

$hfind(name/N, text, N, M, S)

Where S specifies how mIRC will sort the results for the given $hfind:

n: numeric sort
a: alphabetical
c: channel prefix sort
r: reverse order

(the same flags as $sorttok)

Additional 'i' and 'd' flags make mIRC use the tables item and data respectively, instead of using the hord index. All other $hfind() properties are the same, if S is not specified mIRC performs the 'regular' $hfind(). An '.order' property could also be added to the $hget() command.

I'm not sure if this is feasible, however it would be a lot easier and faster then any scripted solution.

Any thoughts? smile
Posted By: codemastr Re: /hord (hash order) - 01/05/03 03:34 AM
If you are asking for sorting in a hash table, then you do not know what a hash table is. If you sort a hash table, then it is no longer a hash table, it is just a random collection of data. If you sort it, it will be come immeasurably slow. If you want it sorted, then you don't use a hash table to store it. Data structures have limits, if they could all do the same exact thing, then multiple structures wouldn't exist. Hash tables are designed to optimize search time. NOT to allow reorganization. In fact, reorganizing a hash table breaks the algorithms and it would no longer be a hash table. It would be like saying I have a car, but instead of driving it on land, I want it to fly. Well then you are no longer talking about a car, you are talking about a plane. They are not the same thing. In the same respect, a hash table and a sorted list are not the same thing. You can't simply make one act like the other.
Posted By: SaX0n Re: /hord (hash order) - 01/05/03 04:39 AM
It's not possible to sort a hash, however, I think that mIRC should have some alternative virtual list type thing. We can script it, but using Listboxes in hidden @windows for this is hardly ideal is it.
Posted By: _D3m0n_ Re: /hord (hash order) - 01/05/03 07:16 AM
why do u need to sort a hash table that is stored into memory ..... its not like u have to SEE it to read it ... ur calling to it for variables and parameters inside of scripts ... thats like asking that you post your entire script to read for everyone to see to do all of your basic functions ..... it doesnt matter how u come to the result .. just that the result exists
Posted By: SaX0n Re: /hord (hash order) - 01/05/03 10:13 AM
There's all sorts of reasons and situations when you would want to have your data sorted. hidden @window listbox's are often used for this purpose. Ofcourse a hashtable can't be sorted. But the requirement for something similair to a hashtable in functionality, and with the ability to sort the data is still there.

I personally would prefer some kind of 'virtual list', (maybe like the StringList in Delphi) or even arrays.

Atleast an option to hide -h windows from the MDI 'window' menu would be nice. There's no need for them to be in the 'Window' menu if they are only exist for utility purposes, and shouldnt be tampered with or closed.
Posted By: qwerty Re: /hord (hash order) - 01/05/03 06:58 PM
You made a lot of good points, I pretty much agree with everything. Hash tables can't, by nature, be sorted; we need a list-type structure; if we stick to -h @windows, there should be a way to hide them completely (perhaps with a new switch?).
© mIRC Discussion Forums