in reply to Populate and sort AoA

The problem is that in your for loop you are removing elements from the array, but your loop will continue iterating until $#display, the size of the array when your loop began. Then within the loop, you are accessing $display[$_][0], which will cause $display[$_] to spring into existence and contain an array reference as its value, even if there is currently no element at index $_. My suggestion is to just use the array reference directly instead of splicing it out and back in: 
my $row;
for my $temp (@display) {
    if ($temp->[0] =~ /^$number$/i) {
         $row = $temp;
    }
}
unless ($row) {
    $row = [$number,' ',' ',' ',' '];
    push @display, $row;
}
$row->[$j] = 'X';

[download]

Replies are listed 'Best First'.
Re^2: Populate and sort AoA
by Tanktalus (Canon) on Nov 15, 2005 at 00:06 UTC

    I thought about that solution, too, but I believe it would change the output - if nedals was going through all that trouble just to reorder things, there probably was a reason. I tried very hard to come up with a solution that would produce the same output as nedals had worked towards.

[reply]

      There is indeed a reason I go to all that trouble.

      The serial numbers are recieved in random order, up to 20K of them. I want the 'operater' to know what were the last 20 serial numbers received (last-in at the top of the list) and what's still missing from the 'group, A-D'. There a section of the script that reads from a database to get serial-number groups that may have been read much earlier (no longer on the last 20 list).

      I could simply get the display data directly from the database, but I concluded that selecting and sorting from 20K records would be time consuming so I decided to maintain a 'last-20' array (or hash) instead.

      Tanktalus, I tried out your hash idea and got it working. I'm not sure which is better. Capturing the serial numbers is easier, but the display gets pretty messy.

      I guess it's a toss up :)

[reply]

        Ok, first I tried to look at the problem from a number of angles. I started by suggesting that you could use a tree (e.g., Tree::Binary) to store things - but the problem is that you want to look up data in multiple ways: by serial number, and by last-in. Look-up by serial number is a hash lookup, while look-up by last-in is an ordered list (ordered on the time of the insert). So then I was about to suggest storing your data simultaneously in multiple containers (since it's all references anyway, it's not going to take up that much space). But then, my fingers and mind got all twisted up trying to describe it.

        That's a good indication that either it's a bad idea, or I don't understand the idea well enough to teach someone. I've been introduced to the idea before, but I've never actually used multiple containers for a single set of data before. So my experience just isn't great enough to really describe it. Then the epiphany.

        You could simply get the display data directly from the database. Set indexes on the serial numbers and the last-insert-time fields. If you get multiple inserts per second, you may need a sub-second time field (I'm not sure if that's standard in RDBMSes or not - I pretty much only use DB2). If you still get multiple inserts simultaneously, it's not really that bad of a thing anyway. You can then query directly for any serial number you want (the database will use a b-tree for index lookup - for 20,000 records, that will mean approximately 14.3 lookups on average), and also query for the 20 highest insert times. Let the database worry about it. It'll use the best algorithms that it can - which you can help by setting up proper indexes.

        Basically, you already have a powerful tool for this, and you're already eating most of the overhead of doing this with that tool. Take advantage of that tool for the rest of it :-)

[reply]

In Section Seekers of Perl Wisdom