Forums Feature Suggestions Arrays

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?

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.

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.

-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

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!

Thanks, Wims. I thought it was a default, undocumented switch. Silly me.

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.

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:
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

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.



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.



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.

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

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.