Thank you for this forum.
It would be like using the same pointer/index but under another key
nid stands for "Numeric ID" and would be a sequential autoincrement integer.
For coding simplification, the concept of NID does not need to be an integer autoincrement. It coul be the memory cell where it the info is stored or the hash used to index it. The integer approach means you compress the key as it allows you use the Nid instead the key as data in other related hash tables.
You can think about storing IP's. On some servers, all IP's are transcoded into something like 5alphnum.5alphnum.virtual . And you can also customize your ip into whatever you can type like "I.hate.virtual.alphnum.ips". It would be very efficient to be able to access such an ip or a long nicknake either through the item in itself and through a numeric id
Possibly it would make it suitable to enable a Nid access function like $hgetnid( htable, Nid ) . I would not say it sounds like a complex coding task. Same data, two indexes.
You could emulate it but at the cost of duplicating (already long) data, and avoiding duplicity of large strings is what I suggest the feature for.
I guess it is needless to say what shocking power this woulkd give to the hash table system.
Please mention me if you decide to code it.
This is very unclear to me, can you give a straight forward example of how it would simplificate?
Let's say you want to track IP's
Some IP's are customized IP's, I.e. very long strings
What's longer "23" or "Dg2ZJK.DtCGyM.virtual"
What's longer "475 or "I.really.love.to.see.the.stars.on.summer.nights"
I could check if user with IP "I.really.love.to.see.the.stars.on.summer.nights" has already chated with me or I could get my internal id of "I.really.love.to.see.the.stars.on.summer.nights" whick could be something like "475" o even "3728" and check If I have ever chated to the internal ip id "3728"
I could write (for instance)
%MyInternalId = $hget(MyIpHashTable, I.really.love.to.see.the.stars.on.summer.nights).nid and then
%MyKey = $me [ $+ [%MyInternalId]]
if ( $hget( MyChattedIpHashTable, %MyKey ) echo -a You already dealt with that IP
And then i could try to check if I dealt with the pair (ident,IP) or (nick,IP) or (Nick, ident, IP) without the need and the space of duplicating long custumised IP's or even short ones.
That gives the power of accessing a long item through a short one (nid) and using the short one to keep track of different combinations of it without the need of using the long one.
Did this make it someting clearer ?
I would be glad of trying to further explain if it didn't.
The indexed ItemId thing is a basic and elementary concept related with the basics of table relationships.
Mirc coders could create a hadd function instead a procedure. That $hadd(table, key, value) would return a key Id and then we could address the possibly long key from other tables through its Id
Tables for Key Identification are called to be 1NF tables and its ID's are used in other tables for attribute setting, while the attribute setting of 1NF tables does not exist or if it is required as it would be in the $hadd function then is set to a single alphanumeric character just to fulfill the attribute requirement
Are my explanationsbeing too complex ?
You can find countless pages about table basic normalization.
Why don't you just create an ID yourself? These are simple hash tables, if you want a database use a database.
Why don't you just create an ID yourself? <<<---- Have you even taken the bother of reading 2 lines besides the subject ? Please do and you will easily find out by yourself.
If using a database were that easy ... what's the point of adding such a thing like a hash table ?
Here the thing is about accessing the same data though an ID, it is as simple as returning an ID when adding a key to the table and being able to access that ID later. 10 lines of code. That's it.
If using a database were how easy? I never claimed it was as easy as a hash table (for someone as godly as you it should be), but if you're looking for more complex features you need to do more complex work.
In a hash table of size 10 hash(key) % 10 is used to find the bucket then iterated through with a comparison on key to find the value. If your ID is not they key it destroys all efficiency in the lookup method.
You gave some reasons to use an ID, but no reason why you can't do it yourself.
How hard is this that mIRC needs to implement it instead of the user? The user can create this index when needed (super easy) and mIRC does not need to add extra switches to implement optional internal index tables that may cause complications in saving/loading tables.
Accessing indexed/hashed data through an index is even quicker than through the key in itself.
It takes 20 lines of code to implement it.
It requires creating a function $hadd() returning the Id
a property .nid for $hget
and a new function for retrieving through Id instead of through key
All the info is already collected and dealt with by mirc and you do not need more for basic database add-ons
Otherwise, hash tables are of very little use and can be laid aside by the mirc-to-mysql add-on
My position is : create something useful or do not create anything at all
And, please, read the thread before answering and many of your questions will get their answers while you are at it, besides of avoiding you make suggestions ... let's be soft saying "out of context or already discarded"
Of course a hash table is useful, they're exposed as dictionary objects in many languages and don't create unique identifiers for you. You didn't address any point made in my posts, mainly: what benefit is there for mIRC to do this which outweighs downside of reimplementation, larger memory consumption, trying to maintain a unique key, and compatibility issues with loading/saving vs having the user create their own ID table in 2 lines?
I read every word in this thread, don't be a child.
Well, I wasn't going to comment here, because I'm neutral regarding the original suggestion. Things got ridiculous now though.
First, in terms of both performance and complexity, you're just wrong. With this feature, mIRC would have to build the index itself, and mIRC then basically has three choices: 1) build a separate index with index reuse, which would make adding items to the hash table more expensive (with O(n) complexity) even when this feature isn't used, or, 2) build a separate index with autoincrement, which would probably have to be a tree structure (with O(log n) complexity) just like in a basic real database, 3) use the memory "cell" as index value, which means mIRC has to validate references given in $hget so as to avoid allowing anyone to crash mIRC with a bad index, and such reference validation would likely.. use an additional hashtable. In none of these cases is the index guaranteed to be faster than the original hashtable. In every case will this take way more than 20 lines of C code to implement.
Second, this feature can be emulated in scripts with an additional hashtable that does reverse mapping. This comes at the cost of roughly doubling the memory needed for all your key strings. For scripters that actually care about this, it really won't be hard to script such functionality, and I say this from experience. Rephrasing the first and second point: your feature suggestion saves memory and does nothing else. Your suggestion might still be useful for certain scripts, but its applicability is limited by nature.
Third, I'm going to assume you didn't really intend to say that hashtables are useless without your feature suggestion, because that suggests that you don't really understand hashtables to begin with.
Here I am looking for an asnwer like :
- Your idea is great, we will implement it.
- Hash tables do what most users can deal with (or not) anyway we think that's enough so far.
And that's all.
What are you looking for ? I know it so the question is for you.
What could we say about someone saying that the first normal form of a table is "your feature suggestion saves memory and does nothing else. Your suggestion might still be useful for certain scripts, but its applicability is limited by nature."
The first normal form is something "limited by nature" ... all right mate.
The number of lines required to do it, dependes on the mind who desings it. You approachs are not the only possible ones nor the best ones.
Interesting comment for a forum about Features .... you weren't going to comment bcs you are neutral ... . I am lucky you are neutral ... if I were your worst enemy ... you could have killed me 3 times.
You could have quoted my words. I think this forum provides a quoting functionality, have you heard about it ? . Quoting could have avoided you the need of changing my words in another clear intent of twisting them. Does a moderator need many more reasons for banning you from these forums ?
First thing I said is that my feature suggestion, among other benefits, would make a great memory saving. You read it and then you think the best thing you can do is recommend for me to duplicate items to emulate the feature. Thank you for your already discarded suggestion.
You said (this is quoting, you see? ) :
1 "mIRC would have to build the index itself"
2 "mIRC then basically has three choices"
I have to say that with the first one you are just wrong
About the secong one is basically wrong and preposterously derived from a wrong one. And I would like to say that I was not going to comment about your post bcs I was neutral about your existence on the planet but things went absolutely out of knowledge, logic or whatever expected in a constructive forum.
If someone does not want to see, there's no way of making they see and anyway my life is not for it.
You can continue twisting my words or saying absurdities one after another, your choice, but I will ignore them.
I think there's something that you (M_A_) are overlooking: Hash tables, by definition, are fundamentally unsuitable for what I understand you to be looking for. This is because the mapping of a value to be hashed to the resultant hash is explicitly and specifically not guaranteed to be unique or reversible. That means that even if you have functionality to look up via the unhashed value, you're not guaranteed to get the answer you're looking for - depending on the hashing function used, hashing alphabetic.host.name.from.here might well generate the same hash value as host.name.from.there.with.bogus.ip - a phenomenon called 'hash collision', and one that is well-known. In a case of collision, how is mIRC - or any program doing hashing - to know whether this is the same value as was hashed before, or merely one that collides? The answer, inherently, is that it can't. The functionality you appear to want seems to be best served by a database where you can guarantee non-collision. How that database is implemented is not specified, and may not matter - except that hash tables ain't the answer. If mIRC were infinitely scriptable in any extant computer language, I'd tell you to look at the TABLE facility in SNOBOL, which appears to be ideal for your needs - but not within mIRC, and I'm not aware of any SNOBOL scripting engine that could be "hooked" into mIRC.
My recommendation is to go back and examine your needs, study and understand the tools that are at your disposal, and then see how best to use those tools to meet your needs. Without focusing on one particular tool that looks cool or is fast or whatever it was that made you decide that hashtables would be the answer "if only".
It sounds like you read a book about databases but didn't really understand it, M_A_. Normal forms are a means to an end, and that end - less redundancy - is not an interesting property for the vast majority of cases where mIRC scripts use hash tables. In a handful of cases, it might be, and that's where people are currently using sqlite and mysql DLLs, etc. Those bring a large number of other desirable database features as well, such as efficient searches. In terms of native database support in mIRC, your suggestion adds just one feature. In the example case that you presented, that one feature achieves just one thing, namely save memory. That is not "shocking power".
Other than that, your last post contains a lot of feelings and no substance. If you want to tell me that I'm wrong, you're going to have to elaborate as to why. Otherwise it sounds like you don't really know what you're talking about.
Thank you for your time
I am aware of what a hash table is and what the current functionalities of mirc hashtables are.
I thought this was a "Feature Suggestion" forum and not a "Refreshing funcionalities" forum.
It is a pity that nobody here can see anything in between the ultra basic features of the current hash table system and a full SQL database. My friends, there are NoSQL databases and what I suggested can be implemented with very few lines.
Anyway, I have realised that no one here is going to write these 30 lines, but instead they could write several pages allegedly arguing why they are not going to do it.
Good luck with the forum that I would like to recall it is a "Feature Suggestion" one ... and nothing else.
It may be worth pointing out that mIRC has only one author, Khaled, and none of us have any direct influence over Khaled's decisions. If he likes your idea, he may still implement it, regardless of whether any of us here think it is a good idea.
This forum, however, is for discussing feature suggestions (it says so in its description!), and that's what we have been doing. If you cannot adequately explain the benefits of your feature suggestion, that may still have an indirect impact on Khaled's opinion (or not, who knows).