in reply to Hash key counting

If you start off with    %column = ( 2 => 1 ); then you'll just keep doing $column{2}= 1 over and over.

This seems like a case where you would want to use push on an array instead. (That is, unless you are planning on deleting things from the middle, in which case you don't want to use 1+number_of_keys as the next column number.) Or since you are only ever putting 1 in, you could simply have a scalar $max_column_number that you increment.

Even after reading 3 explanations from you about this code, I still don't see why you want to put data into a hash in this manner. How do you use this hash elsewhere?

                - tye

Replies are listed 'Best First'.
Re: Re: Hash key counting (2=>1)
by agentv (Friar) on Apr 21, 2003 at 23:33 UTC

    ...I can see what's going on here very clearly. The data is being stored in a hash using keys which are expected to be sequentially numbered integers. Or in simpler terms, we're taking a hash and making it perform as an array.

    But, as others point out here, if the hash is initialized (or manipulated) in an unexpected way, the scheme breaks down.

    Not to be glib, but...

    I eat my peas with honey.
    I've done it all my life.
    It makes the peas taste funny.
    But it keeps them on the knife.

    Unless there's some rationale that is not clear from the original code snippet, I'd say use an array instead of a hash. Then push() will reduce the amount of logic required to get your information into the data structure.

    ...All the world looks like -well- all the world, when your hammer is Perl.
    ---v

      To give the OP a few possible rationales:
      1. My array would get so big, but is sparsely populated
      2. My stuff isn't sequential (kinda doesn't work in this case, but is a good excuse, in general...)
      3. I need to do a lot of random-access lookup
      I give up. Essentially, imho, this is pointing out that the OP is trying to solve a problem without fully understanding the requirements necessary. If s/he did, then a less complex solution would probably point itself out very quickly.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        My array would get so big, but is sparsely populated
        How is that an argument in this case? He's adding sequentially numbered keys, so the population is as dense as at all possible.

        Makeshifts last the longest.