Re: Underestimage (ST vs brute force)

I wasn't the one who suggested the non-ST solution, but I did bring up the possibility that ST *might* be slower for smaller sets in this case. Thanks for showing it's not. This contradicts numbers I thought I had seen in the past.

By the way, I think you'll get even more speed if you avoid curlies around map.

my @s = map $_->[0],
        sort { $a->[1] <=> $b->[1] }
        map [ $_, (/(\d+)/)[0] ],
        @l;
[download]

Comment on Re: Underestimage (ST vs brute force) Select or Download Code

Replies are listed 'Best First'.
Re^2: Underestimage (ST vs brute force) by Tanktalus (Canon) on Dec 09, 2008 at 19:17 UTC
I'm sure we could get more speed that way, but that does defeat the primary purpose behind my suggestion for the ST: maintenance. You put back in the one thing I was trying to eliminate for the poor original petitioner: `(/(\d+)/)[0]`. By using a block, focused on a single item at a time, I could split that into multiple statements to make it easier to read. The first curlies could be removed with little ill effect on readability, but the curlies on the second map would be a negative to readability. And, so, I suggest, a premature optimisation :-P	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: Underestimage (ST vs brute force)
by Tanktalus (Canon) on Dec 09, 2008 at 19:17 UTC

I'm sure we could get more speed that way, but that does defeat the primary purpose behind my suggestion for the ST: maintenance. You put back in the one thing I was trying to eliminate for the poor original petitioner: (/(\d+)/)[0]. By using a block, focused on a single item at a time, I could split that into multiple statements to make it easier to read.

The first curlies could be removed with little ill effect on readability, but the curlies on the second map would be a negative to readability. And, so, I suggest, a premature optimisation :-P

[reply]
[d/l]