in reply to Re: array problems
in thread array problems

Here is what I came up with (I'm just using the example of the operator "+" because that is the only one I _need_ right now):

use List::Util;
use Algorithm::ChooseSubsets;

...<lots of stuff snipped here>...

  # Generate sums of the values of all combinations of my picks
  my @to_trade1;
  
  for (my $i=0; $i < $roster_spots; $i++) {
    my $record={};
    my $this_pick = $pick_by_team[$brett_team][$i];
    if ($this_pick > $draft_pick) {
      push @to_trade1, $this_pick;
    }
  }
  
  my @to_trade = {};
  for (my $i = 2; $i < $#to_trade1; $i++) {
    my $subset_list = new Algorithm::ChooseSubsets(\@to_trade1, $i);
    while (my $this_set =  $subset_list->next()) {
      my $record={};
      $record->{"LIST"} = [ @$this_set ];
      $record->{"VALUE"} = List::Util::sum @$this_set;
      push @to_trade, $record;
    }
  }

  print Dumper(@to_trade);

[download]

This works, but is pretty slow...I have to respond to trades within a minute so, I may try some ways to speed it up!

Replies are listed 'Best First'.
Re: Re: Re: array problems
by BrowserUk (Patriarch) on Aug 12, 2003 at 21:35 UTC

    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

    Read more... (854 Bytes)

    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.
[reply]
[d/l]

      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