returns in this order: starting with $hget(quetest,1) - 3
I think you meant $hget(quetest,1).ITEM ,since there is no itemname "1" "2" or "3" created with in my code i doubt there would be any results.
That looks semi random to me
You know that because you've scripted something? I'm sure hundreds have scripted something using hash tables, that possibly do the same thing you showed me. But it didn't work when I tried it and i'm not that fimilar with hash tables enough to try and solve the code myself. That's a long run-on sentance
.
It might look random to you but they are being inserted into a table at specific points based apon there itemname and any previous entries that were inserted into the same slot based on there itemname before them. That is not random, it is a caluclated method, designed to allow the quick retrieval of them when there itemname is placed in the $hget(table,itemname). And I know this not only becuase my script shows the result of it, but also becuase i understand how the hashtable works, I have used hashing to index into records possably before you used a pc. you yourself admit you are not familar with them, which kinda shows up in your incorrect assumptions below.
Hash tables do add randomly. they dont
Random not meaning it picks out a slot on it's own, it does do that
just the first free one. it doesnt do this
Hash tables are stored in system memory correct? The RAM? RAM stands for Random access memory. Close enough to correct
When available slots open in the ram area the data goes in. ram is not allocated in this fashion
Hash's do the same thing. no they dont
Suppose you add to a hash file, the item name: apple, you hget the first entry and it's apple. Then you add: orange, it may be the second entry. Add: banana it could now be the third entry. you remove orange from the hash table, that slot in the hash is freed. Doesn't seem very ordered
. Items stored in any free slot inside of 100 slots given no order to their storage = random.
Sorry but your assumptions are wrong.
Ok im going to show you how it actually works.
/hmake ex 100101 slot table created slot numbers from 0 to 100
/hadd ex apple xitemname "apple" inserts into slot 97, $hget(ex,1).item = "apple" due to no other slots before 97 in use.
/hadd ex orange xitemname "orange" inserts into slot 89, $hget(ex,1).item = "orange" ,2 = "apple" due to no other slots in use.
/hadd ex banana xitemname "banana" inserts into slot 4, $hget(ex,1).item = "banana" ,2 = "orange" ,3 = "apple" due to no other slots in use.
/hadd ex peach xitemname "peach" inserts into slot 38, $hget(ex,1).item = ,"banana" ,2 = "peach" ,3 = orange" ,4 = "apple" due to no other slots in use.
This can be shown in this set of commands.
//tokenize 32 apple orange banana peach | hfree -w ex | hmake ex 100 | hadd ex $1 1st | hadd ex $2 2nd | hadd ex $3 3rd | hadd ex $4 4th | echo -a $hget(ex,1).item : $hget(ex,2).item : $hget(ex,3).item : $hget(ex,4).itembanana : peach : orange : appleor using any combination such as peach apple banana orange the result well be the same.
Now some people may ask what happens if two different itemnames happen to hash down to he same slot, well the slot is detected as having an entery in it already however each slot appears to infact be a linked list of entries, so any number of itemnames can appear in any one slot. How they are physically mapped into memory i have a feeling might be using uid's but as to the hashtable they appear in the order of the slot they are hashed too, followed by the order of items added to the slot.
PS: the slot numbers mentioned above are the actual slot numbers of those itemnames, i didnt just make that up.
