in reply to Re: Re: array problems
in thread array problems

If your array size is always the same, then you can avoid having to regenerate the combinations each time.

In my version above, if you look closely you'll see that I don't permute the array elements. I permute the indices and the use those to slice the array. If your array is always the same size, you can do this once and reuse the indices each time which will save a fairly costly recursive generation each time.

A modified version of the above code to show this

#! perl -slw
use strict;
use vars qw[ $a $b ];
use List::Util qw[ reduce ];

my @indices = map{ Cnr( $_, 0 .. $#ARGV ) } 2 .. @ARGV;
my @hasharray;

push @hasharray, {
    LIST=> [ @$_ ],
    VALUE=> reduce{ $a + $b } @ARGV[ @$_ ]
} for @indices;

print "@{ $_->{LIST} } : $_->{VALUE}"  for @hasharray;

exit;

sub Cnr{
    my( $n, @r ) = shift;
    return [] unless $n--;
    for my $x ( 0 .. ($#_ - $n) ) {
        push @r, map{ [ $_[$x], @$_ ] } Cnr( $n, @_[ ($x+1) .. $#_ ] )
+ ;
    }
    return @r;
}

[download]

If your array size varies, but over a short range, then you could use Memoize to cache the generation and only do it the first time a new array size is encountered.

As Algorithm::ChooseSubsets permutes the array rather than the indices, Memoizing that wouldn't reap the same rewards.

There is also a performance penalty from using OO-style interfaces, especially to inherently procedural algorithms. Most of the time this is pretty insignificant, but when it means issuing a call once each time around a loop instead of once at the top of the loop, then the overhead becomes a burden.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.

Replies are listed 'Best First'.
Re: Re: Re: Re: array problems
by bfish (Novice) on Aug 13, 2003 at 14:49 UTC

    Hmmmm...

    My array size does vary (each time a pick is executed, it is possible to lose a pick that was in the array previously as that pick can no longer be traded). This variance, as you mentioned is minimal...I'll check Memorize. The array, however, can also morph. If picks are traded, then the number of picks doesn't change, but the picks available to be traded does. I'll have to see what happens to memorize when I try that.

    In the end, however, I have a feeling that I'll be regenerating the array pretty often as my plan was to kick off the trading application every time a new pick was made and kill the version of the trading application currently running. I'm having to do it this way 'cause I'm running on a windows system and can't figure out how to send true interrupts (or, even, how to deal with them if I could send them!). On a UNIX box, I could handle this no problem, but I don't have time before the draft to rewrite my app using a UNIX interface and then load UNIX onto a spare laptop. Yes, I curse that I used Windows to begin with, but this very involved program began as an effort to understand how to use PERL GUI apps under windows...

[reply]

      The morphing of the array doesn't affect the indexing, so that isn't a problem. (It's Memoize BTW, no 'r').

      As for the 'interupts problem'. There are many ways of interprocess communication available under Win32, they are just different to *nix. Perls attempts to layer signals on top of windows has never been very sucessful. That said, from what I read, the whole idea of using signals in perl, even under *nix has never really been made to work very well.

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
      If I understand your problem, I can solve it! Of course, the same can be said for you.
[reply]

In Section Seekers of Perl Wisdom