mIRC Home    About    Download    Register    News    Help

Print Thread
Page 2 of 2 1 2
hixxy #233767 09/09/11 11:15 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: hixxy
I don't really care about the implementation, would just like the feature.

It doesn't really make a difference if we have to use: (code sample 1) Or (code sample 2)

Does it?


It does, though.

~6 new commands, 5 new identifiers, and a plethora of new documentation that not only has to all be kept in sync, but adjusted if any features shared between hashes and arrays ever change. Let me pose it to you the other way: do we really need an $hfind *and* an $afind?


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #233777 10/09/11 10:25 AM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
Joined: Sep 2005
Posts: 2,881
I'm talking about from a user perspective. None of that matters to me; it may matter to Khaled (I suspect it would), but that's for him to decide.

As a user, it makes no difference to me what the implementation is so long as the feature is there. There seems to be little point in debating over the implementation when it makes no difference to the end user. Khaled is capable of making up his own mind.

hixxy #233778 10/09/11 11:10 AM
Joined: Jul 2007
Posts: 1,129
T
Hoopy frood
Offline
Hoopy frood
T
Joined: Jul 2007
Posts: 1,129
Could you be kind enough to answer my question before Argv0's? It seemed to have been left out in the cold to favor the debate that's going to be up to Khaled ultimately.

Last edited by Tomao; 10/09/11 11:19 AM.
Tomao #233781 10/09/11 11:47 AM
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
-i for hmake is what argv0 proposed to tell to mIRC it is an array rather than an hash table, so mIRC can use the appropriate data structure internally


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Onions #233782 10/09/11 12:13 PM
Joined: Feb 2006
Posts: 546
J
Fjord artisan
Offline
Fjord artisan
J
Joined: Feb 2006
Posts: 546
mIRC really needs a list structure even if it is just a pseudo @window that could be used with (some) window related commands but only involved a line buffer and no window creation and drawing. i'm all for an implementation of arrays that addresses this shortcoming!


"The only excuse for making a useless script is that one admires it intensely" - Oscar Wilde
Wims #233788 10/09/11 08:30 PM
Joined: Jul 2007
Posts: 1,129
T
Hoopy frood
Offline
Hoopy frood
T
Joined: Jul 2007
Posts: 1,129
Thanks, Wims. I thought it was a default, undocumented switch. Silly me.

Wims #233791 11/09/11 05:07 AM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Well no, I'm not asking for mIRC to use a different data structure, as hashes work fine. mIRC just needs to treat the keys as integers rather than strings, and shift indices on insert/delete, though this part is optional.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #233795 11/09/11 03:32 PM
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
Originally Posted By: argv0
Just FYI, mIRC could always optimize a hash table for insertion/deletion if a switch was supplied during creation. This is why I had previously suggested the -i switch in the thread you linked, to tell mIRC to optimize the keys as indexed integer values. Using such a switch, mIRC could collapse/shift indexes during insertion/deletion-- or even just store the internal structure as a pure array for super-duper-efficiency, if Khaled wanted.
Then, why did you emit that idea (in bold) if it's not because you know that's what people want, especially when you know that's the best thing to do for efficiency ? I thought you wanted to keep the hash table syntax for simplicity but that you still wanted a real array internally.
Saying you want -i only for the shifting part because it would allow us to have an array-like way to store data is wrong for two main reasons: that's not the good way to do it (but you know that) and:
Quote:
The fact remains that most users aren't concerned about the efficiency differences in deleting items in an Array
this is your opinion, not fact, and they might be much more people that would use the real advantages of an array than what you think.
As a last resort, this is how you argued several time in the past so make your choice:

1) I want to see real array implemented with all the efficiency it implies
2) I want to see array implemented using hash table, with all the inefficiency it implies

Last edited by Wims; 11/09/11 04:10 PM.

#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #233796 11/09/11 07:10 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Originally Posted By: Wims
Then, why did you emit that idea (in bold) if it's not because you know that's what people want


If you bolded the full phrase, I added: "if Khaled wanted". It certainly wouldn't be my choice of implementation, I'm just laying out all the options. I've made it clear quite a few times what I'd like to see, but of course I realize there are other opinions involved.

Originally Posted By: Wims
it would allow us to have an array-like way to store data is wrong for two main reasons: that's not the good way to do it


It's "wrong" because "that's not the good way to do it"? That's pretty vague-- care to elaborate? I don't see any idiomatic problems with storing array data in an associative structure-- it would be equivalent to storing an array of array pointer structures internally in C (minus the tiny overhead of the linked list hash structure that goes along with a hash impl). The point of -i would be to optimize the insertion/deletion by changing the hash function to simply be h(n) = n, and, again optionally, ensuring that only 1 value can be associated with a key by shifting on h(n+1) or h(n-1).

Reusing the existing hash infrastructure would mean a more stable implementation that takes advantage of all of the existing features for hash tables, of which there are many. Some of which you might be discounting are $hfind, /hsave, and /hload, any of which risk being omitted from an initial array implementation-- all of which, would share many important use cases for array structures. This is the argument I am posing.

Originally Posted By: Wims
1) I want to see real array implemented with all the efficiency it implies
2) I want to see array implemented using hash table, with all the inefficiency it implies


These two options are not mutually exclusive, and are also loaded logical fallacies. The "inefficiency" that everyone is pointing to regarding hash tables is unfounded and based solely on mIRC's parsing capabilities, not the efficiency of hash structures themselves. In other words, the claim is misplaced. Also note that there is nothing inherently more efficient about arrays and hashes. Let's review some CS 101:

Hash table lookup: O(1). Array lookup: O(1).

We're even so far.

Hash table deletion: O(1). Array deletion: O(n).

Hashes are more efficient! This of course implies different behaviour, though-- to make it fair:

Hash table deletion with shifting: O(n). Array deletion: O(n).

Equal. Insertion is the same.

So, show me where arrays are significantly more efficient? The theory shows that you are wrong-- many existing efficient hash implementations would agree with the theory (to the point where our own basis of benchmarking, $ticks, would probably not be able to differentiate). And, especially since most of the overhead in hashes can be optimized out if you know your key values are integer indexes, it almost becomes moot.


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"
argv0 #233797 11/09/11 08:09 PM
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145
I didn't think -i would change the hash function, just do the shifting with the actual implementation, it's what I called the wrong way to do it


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Wims #233798 11/09/11 09:20 PM
Joined: Oct 2003
Posts: 3,918
A
Hoopy frood
Offline
Hoopy frood
A
Joined: Oct 2003
Posts: 3,918
Even if it didn't change the hash function, the performance difference would be minor. Again, we're talking only the cost of overhead of a function that's probably not much more complex than sumof(characters) % bucketsize. If you want specific timings, you could probably implement proof of concept implementations, but I doubt you'll see a significant cost. And the benefits I described justify the cost IMO. That's not the wrong way to do it.


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

Link Copied to Clipboard