Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re: split to hash, problem with random keys

by MrCromeDome (Deacon)
on Jul 03, 2003 at 16:43 UTC ( [id://271222]=note: print w/replies, xml ) Need Help??


in reply to split to hash, problem with random keys

The pseudo-random order is because your hash information is stored in (of all things) a hash table. It's not truly pseudo-random: it's the order in which Perl's hashing routines have decided is the most optimal way to store your data.

Why? Because as shemp says, "it's faster!"

If you want things done in a particular order, the excellent suggestions above will be of great use to you.

Cheers!
MrCromeDome

  • Comment on Re: split to hash, problem with random keys

Replies are listed 'Best First'.
Re: Re: split to hash, problem with random keys
by december (Pilgrim) on Jul 03, 2003 at 17:27 UTC

    It's not by size or alphabetical. Just out of curiosity, do you know more about the logic in the order those hashing routines sort the data?

    Thanks for your insight.

      do you know more about the logic in the order those hashing routines sort the data

      There is no ordering principle in Perls hash implementation. In fact the hashes are statically initialized with a pseudorandom sequence at launch. The order that follows from there is strictly incidental to anything else. The only thing that you are currently promised is that you will get the same sequence from the same set of keys that were inserted into the structure. (This is order dependent. Change the order in which you insert keys into the hash, and the output sequence will differ as well.)

      And get this: Its going to get worse. There is a DOS attack that is based around targetting vulnerabilities in the hash algorithm causing perl to slow to a crawl while populating the hash. In order to resolve this the hash will no longer be initialized with a static pseudorandom sequence, instead it will be initialized with dynamic pseudo random sequence. Thus there will be no guaranty that the same set of inserts will produce the same order of keys on two different runs.

      The moral of this story is that if you want your code to be forward compatible with later versions of perl then you had better not depend on native key order in any way at all. If you need to do this then sort the keys.

      It should come to no suprise to people that there is lots of code out there that will be subtly broken by this change. People depend on the repeatability of hash keys more often than they think they do.


      ---
      demerphq

      <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
        Just a question on this, because I can't be bothered to dig it out myself. Will something the following still work as expected?
        my %new_hash; @new_hash{map munge($_), keys %old_hash} = value %old_hash;
        This depends on the sequence of elements returned being identical and is the only way I ever depend on order in a hash.

        Makeshifts last the longest.

      My knowledge of data structures is spotty at best. I imagine that consulting
      perldoc perlguts
      would shed some light on this matter though.

      MrCromeDome

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://271222]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others musing on the Monastery: (9)
As of 2024-04-19 16:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found