in reply to Comparing Arrays

Just figured I'd add another way to do it... 
sub quote_eq {
   return "@a1" eq "@a2";
}

[download]
And the results were.... 
Benchmark: timing 100000 iterations of join, loop, quote...
      join:  3 wallclock secs ( 2.30 usr +  0.00 sys =  2.30 CPU) @ 43
+402.78/s (n=100000)
      loop: 17 wallclock secs (16.03 usr +  0.00 sys = 16.03 CPU) @ 62
+37.52/s (n=100000)
     quote:  5 wallclock secs ( 3.79 usr +  0.00 sys =  3.79 CPU) @ 26
+420.08/s (n=100000)

[download]
join remains in the lead...

Update: Of course this has the same bug that lhoward pointed out. Assuming lists of single character elements though... :)

Update 2: Alright, so not the same bug, but a similar bug - as btrott points out... i.e. 
my @a1 = ( "3 5 7", "9 11 13" );
my @a2 = qw( 3 5 7 9 11 13 );

[download]
result in the same string. So this algorithm can be used to compare arrays where the elements don't have whitespace... any array created with the qw operator...

Replies are listed 'Best First'.
RE: RE: Comparing Arrays
by btrott (Parson) on Sep 01, 2000 at 22:51 UTC
    No, that doesn't have the same bug. The bug in the other code was because the join was done on the empty string, which makes the list (3, 5, 7) collapse to "357". When you quote an array, the implicit join is done on the special character $", which by default is a space. So: 
        my @a1 = qw/357/;
    my @a2 = qw/3 5 7/;

    print "@a1\n";
    print "@a2\n";

    [download]
    Gives 
        357
    3 5 7

    [download]
    Different strings.

    You could change $" to be something weirder when doing the comparison; something less likely to be found in a string normally. Like $;: 

        sub areq {
        local $" = $;;
        "@{$_[0]}" eq "@{$_[1]}";
    }

    [download]
[reply]
[d/l]
[select]
      Either way it'll still contain a very similar error. If you pick a "separator" you must guarantee that it won't appear in any of the list element in order to prevent this error. This "string" method can still be shown to perform improperly with certain arrays: 
      my @a1=('3 5 7');
my @a2=('3','5','7');

      [download]
[reply]
[d/l]
        you can avoid this error by performing the test twice, changing the separator between the two tests. i believe (until someone can show me a counter example) that it is impossible to construct two different arrays that will pass this test twice with different separators. ( <--- was that really english? wow was that poorly written. )

        jeff

        Update: this post was mostly to show how to avoid the error in the stringifying subroutine, but i also did some benchmarking. and... here's what i've found. testing with two separators takes about the same amount of time as looping if the arrays are identical. i don't really know about memory requirements though.
[reply]

In Section Cool Uses for Perl