If the values in @F are very sparse, you should probably use a hash to make the reverse map instead of the array @G. If you had a case where @F = qw/1 3 5 1000000 2000000/;, you wouldn't want to reverse map that into an array, which would become 2 million elements large. Apart from that, it's just plain easier to write a reverse map into a hash: @G{@F} = ();

It's not clear to me from your description, but is the thing you really want the set intersection of the set @F with 25..35 and with 50..75? If this is the case, maybe one of the Set:: or Array:: modules might be worth inspecting (Set::IntRange?). Although I'm not familiar with what's out there, I would assume there would be some modules out there highly optimized for the intersection operation.

If you're not looking for a set intersection, I don't see any obvious optimizations here, other than the possible sparseness of the reverse map that I mentioned.

Update: I noticed your code always returns a range, even if some of the intermediaries in the range aren't in @F. thinker gives a very nice algorithm for set intersection with a range, but if you need to always return a range (even including elements not in @F), here's an adaptation:

sub range{
  my($lo, $hi) = @_;

   ($lo, $hi) = (sort grep {$_ >= $lo and $_ <= $hi} @F)[0,-1];
   return $lo..$hi;
}
[download]

Depending on the data, this might be better than your original code. While this has to process your entire set of values, if the values are extremely sparse, you may end up ++'ing $lo and --'ing $hi all day in your algorithm.

blokhead