in reply to Re: Managing Client Specific Hashes
in thread Managing Client Specific Hashes

In my mind its bad to have arrays with 'willy-nilly' indexes... such as:index 9 is valid.. index 31 is valid... but 10 through 30 are not...this is bad practice correct? and yes they are always sorted when I use them. I would be sorting the array by index and not value... I'm not understanding why you think an array is a viable option... please explain that.. I would like to understand.


Grygonos
  • Comment on Re: Re: Managing Client Specific Hashes

Replies are listed 'Best First'.
Re: Managing Client Specific Hashes
by Abigail-II (Bishop) on Jan 13, 2004 at 15:56 UTC
    I would be sorting the array by index and not value... I'm not understanding why you think an array is a viable option... please explain that.. I would like to understand.
    So, you are sorting the array (I think you mean the list of keys here), but you don't think an array is a viable option? Storing the data in a sorted array instead of storing them in a hash, and sorting it before usage, eliminates a step.

    Abigail

      but the key is important data as well... the key is where the data field begins... and that hashes to how long the field is... can you present a sample array that does what you propose? Thanks if you have time.

      Grygonos
        my @a = ([ 1, 8], [ 9, 11], [ 20, 2], [ 22, 9], [ 31, 7], [ 38, 8], [ 46, 8], [ 54, 8], [ 62, 30], [ 92, 12], [104, 30]);
        Or if your array is large, and you want to save memory:
        my @b = ( [1, 9, 20, 22, 31, 38, 46, 54, 62, 92, 104], [8, 11, 2, 8, 7, 8, 8, 8, 30, 12, 30] );
        But if you look carefully, the "keys" aren't necessary at all - if all you do is process the data in order, the keys can be calculated from the values, and all you need to keep is:
        my @c = (8, 11, 2, 8, 7, 8, 8, 8, 30, 12, 30);

        Abigail