Re: Re-orderable keyed access structure?

Greetings all,
After much discussion with BrowserUK I realized I was barking up the wrong tree...
Perhaps you could store the value of the key in the hash based index as the first element of the data its pointing to? That way the first element of each of the original arrays would be the key of the hash used to access it. The key can be used to get the array or vice versa.

use strict; my @ref_array = ([state,pointer],[state,pointer],[state,pointer]); my $i = -1; my %key_index = map($i++; unshift(@{$_},$i); $i,\$_;)@ref_array;
[download]

Of course I have not tested this (my BSD partition is mad at me presently). But I think the logic will satisfy your 3 requirements.

UPDATE:(Aug.16th)
Just a quick note the my @ref_array illustrated above was meant to represent the original items mentioned in the original post. The [state,pointer] is in reference to another post in which the structure of the original items was explained...
my apologies for the confusion.
example below:
This is what I was talking about.
%key_index items in anon.arrays (@ref_array in my post) { 0 => \itemA } [ 0, status, dataA ] { 1 => \itemB } [ 1, status, dataB ] { 2 => \itemC } [ 2, status, dataC ]
[download]

this way the key (0-2 in the example) is stored with the original data. that way you can always get the key of the index_hash from the element itself. The shuffling should not matter at that point.

-injunjoel

"I do not feel obliged to believe that the same God who endowed us with sense, reason and intellect has intended us to forego their use." -Galileo

Comment on Re: Re-orderable keyed access structure? Select or Download Code

Replies are listed 'Best First'.
Re^2: Re-orderable keyed access structure? by Aristotle (Chancellor) on Aug 15, 2004 at 01:40 UTC
Note that anonymous arrays aren't free. Their memory consumption grows alarmingly when you have 6-digit amounts of them. Since you have a fixed amount of two elements per anonymous array, it is advisable to flatten that AoA to two parallel named arrays. I would not normally be giving this advice; in general, it is better to keep things that belong together, together. With two arrays, you will need to maintain the code to do all operations twice, and the CPU will need to execute all operations twice, as well. It violates the DRY principle. But as someone who's dealt with 600MB Perl processes, I know the pain of too-deep structures. When you're slinging around huge amounts of data, the extra CPU cycles spent to maintain parallel structures are easily offset by the amount of additional data you'll be able to fit into memory at once (and therefor, going to disk much less frequently (particularly if, goodness forbid, you'd otherwise end up swapping.)) Makeshifts last the longest.	[reply]

Replies are listed 'Best First'.

Re^2: Re-orderable keyed access structure?
by Aristotle (Chancellor) on Aug 15, 2004 at 01:40 UTC

Note that anonymous arrays aren't free. Their memory consumption grows alarmingly when you have 6-digit amounts of them. Since you have a fixed amount of two elements per anonymous array, it is advisable to flatten that AoA to two parallel named arrays.

I would not normally be giving this advice; in general, it is better to keep things that belong together, together. With two arrays, you will need to maintain the code to do all operations twice, and the CPU will need to execute all operations twice, as well. It violates the DRY principle.

But as someone who's dealt with 600MB Perl processes, I know the pain of too-deep structures. When you're slinging around huge amounts of data, the extra CPU cycles spent to maintain parallel structures are easily offset by the amount of additional data you'll be able to fit into memory at once (and therefor, going to disk much less frequently (particularly if, goodness forbid, you'd otherwise end up swapping.))

Makeshifts last the longest.

[reply]