James Edward Gray II wrote: > On Friday, June 6, 2003, at 03:32 AM, R. Joseph Newton wrote: > > > The player's name IS the number. No other numbering system is > > needed. The players name is NEVER stored in the hash, AFAIK. The > > name is used to feed a hashing function, which renders an index into > > the storage of the hash structure. There is found the count-- the > > ONLY DATA stored for any player/number., > > Well, I think we got Stuart sorted out a few days ago,
Whoops. sorry, I've been off in the land of Real Life, so I'm a bit behind. > but since you > bring it up I prefer to think of a hashes as stored pairs, no matter > what they really are. You could be right about the key not being > stored, I honestly have no clue. Things like keys() and each() have to > get it from somewhere though (Reversing the hashing operation? Again, > no clue.) and since they do exist, it's easier for me to think of them > as a key and value pair being stored. Of course, this is all just > opinion and I'm sure other programmers have different views from either > of us. > > James Sounds like that works. There are reasons, though, to bear in mind that the pairing relationship is not symmetric. For instance, in the players table, er hash, the values are numbers of jumpshots. Say five different players ahve all completed three shots apiece. Are you going to be able to reverse-reference here? Sorry I went over the top in the above statement. I am just trying to emphasize this point as strongly as possible. Over the last few months, I have seen many posts indicating a misunerstanding of this assymetry in reference, and the muddle of hash/array conversions in which the OP was getting caught led me to think that breaking the link between hash and list was important in his case. It looks like I am going to have to perr into perlguts and the C source a bit. I have been assuming that the Perl hash is, under the hood, a hash structure in the general algorithmic sense. I could well be mistaken on this, but the references to the lightning-fast performance of these structures leads me to think this. A structure which stored only a list of pairs would have seek times of O(n). A structure using a hashing algorithm will have primary indexing times of O(1), with a generally trivial amount of processing required afterward to resolve index collision cases. In this second phase, though, I must grant, storage as pairs would be critical in final resolution of the element. My hunch--and it is only a hunch--is that Larry chose to structure this in the latter manner, both for performance reasons, and out of respect for the existing usage of the term "hash" in data structure nomenclature. Joseph -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
