[33166] in Perl-Users-Digest
Perl-Users Digest, Issue: 4445 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jun 4 14:09:18 2015
Date: Thu, 4 Jun 2015 11:09:05 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 4 Jun 2015 Volume: 11 Number: 4445
Today's topics:
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <derykus@gmail.com>
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <gamo@telecable.es>
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <tzz@lifelogs.com>
Re: Comparing Lists <gamo@telecable.es>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Re: Comparing Lists <uri@stemsystems.com>
Re: Comparing Lists <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 03 Jun 2015 09:53:10 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <87a8wglwzd.fsf@lifelogs.com>
On Thu, 28 May 2015 14:10:32 -0700 (PDT) "C.DeRykus" <derykus@gmail.com> wrote:
>> Is there a simpler, more-direct way to do list comparisons?
CD> Assuming no binary data or memory-busting lists:
CD> say "same" if join("\0",@list1) eq join("\0",@list2);
Even disregarding the inefficiency, it's annoying to get warnings about
undefined values, and of course, you probably don't want to treat "" the
same as undef... which converting it to a string will do.
Here's a simple version, lightly tested.
Ted
#+begin_src perl
sub differ
{
my @list1 = (undef,2,3);
my @list2 = (undef,2);
return 1 if scalar @list1 != scalar @list2;
my $differ = 0;
while (scalar @list1)
{
my $x = pop @list1;
my $y = pop @list2;
# xor
return 1 if (defined $x && !defined $y) || (!defined $x && defined $y);
# because of the above, we now know $x and $y are either both defined
# or both undefined (the latter case makes them equal)
return 1 if (defined $x && defined $y) && ($x ne $y); # note this assumes you want string equality
}
return 0;
}
#+end_src
------------------------------
Date: Wed, 3 Jun 2015 10:15:00 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Comparing Lists
Message-Id: <ffbcde6a-e560-4a41-96ea-885ca9b645e5@googlegroups.com>
On Wednesday, June 3, 2015 at 6:53:16 AM UTC-7, Ted Zlatanov wrote:
> On Thu, 28 May 2015 14:10:32 -0700 (PDT) "C.DeRykus" <derykus@gmail.com> wrote:
>
> >> Is there a simpler, more-direct way to do list comparisons?
>
> CD> Assuming no binary data or memory-busting lists:
>
> CD> say "same" if join("\0",@list1) eq join("\0",@list2);
>
> Even disregarding the inefficiency, it's annoying to get warnings about
> undefined values, and of course, you probably don't want to treat "" the
> same as undef... which converting it to a string will do.
>
> Here's a simple version, lightly tested.
>
> Ted
>
> #+begin_src perl
> sub differ
> {
> my @list1 = (undef,2,3);
> my @list2 = (undef,2);
>
> return 1 if scalar @list1 != scalar @list2;
>
> my $differ = 0;
> while (scalar @list1)
> {
> my $x = pop @list1;
> my $y = pop @list2;
>
> # xor
> return 1 if (defined $x && !defined $y) || (!defined $x && defined $y);
>
> # because of the above, we now know $x and $y are either both defined
> # or both undefined (the latter case makes them equal)
>
> return 1 if (defined $x && defined $y) && ($x ne $y); # note this assumes you want string equality
> }
>
> return 0;
> }
> #+end_src
Of course with no "memory-busting lists", efficiency may not be concerning; undef warnings easily quashed; and "" treated same as undef a non-factor.
Or not...
------------------------------
Date: Wed, 03 Jun 2015 15:34:57 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <87y4k0k2la.fsf@lifelogs.com>
On Wed, 3 Jun 2015 10:15:00 -0700 (PDT) "C.DeRykus" <derykus@gmail.com> wrote:
CD> Of course with no "memory-busting lists", efficiency may not be
CD> concerning; undef warnings easily quashed; and "" treated same as
CD> undef a non-factor.
CD> Or not...
I think a correct efficient solution is strictly more useful, so I'll
just point to List::Compare on CPAN now.
Ted
------------------------------
Date: Wed, 03 Jun 2015 21:54:03 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87lhg0cy38.fsf@doppelsaurus.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Wed, 3 Jun 2015 10:15:00 -0700 (PDT) "C.DeRykus" <derykus@gmail.com> wrote:
> CD> Of course with no "memory-busting lists", efficiency may not be
> CD> concerning; undef warnings easily quashed; and "" treated same as
> CD> undef a non-factor.
>
> CD> Or not...
>
> I think a correct efficient solution is strictly more useful, so I'll
> just point to List::Compare on CPAN now.
"I believe something which can be downloaded for free from ... also
solves the problem" doesn't really answer the original question,
especially not without at least showing an example of how it's supposed
to be used (in this case, it would need just about as much code to be
written as a direct comparison routine in order to execute some part
of hundreds of lines of code hidden in the module). Also, there is
really no 'correct' way to compare two lists in Perl as the choice of
==/ != vs eq/ ne vs 'something completely different', eg $a - $b <
0.0001 for comparing floating point numbers and whether or not undef
needs to be handled and how it is supposed to be handled depends on the
situation.
Eg, a subroutine which expects references to two arrays whose elements
can be compared via eq/ne but which avoids uninitialized value warnings
and distinguishes between undef and an empty string, testing the 'lists'
for equality, could look like this:
sub zl_eq
{
local (*a, *b) = @_;
defined($a[$_]) ? defined($b[$_]) && $a[$_] eq $b[$_] : !defined($b[$_]) or return
for 0 .. $#a;
return 1;
}
------------------------------
Date: Wed, 03 Jun 2015 23:02:12 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <874mmocuxn.fsf@doppelsaurus.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
> Eg, a subroutine which expects references to two arrays whose elements
> can be compared via eq/ne but which avoids uninitialized value warnings
> and distinguishes between undef and an empty string, testing the 'lists'
> for equality, could look like this:
>
> sub zl_eq
> {
> local (*a, *b) = @_;
There's a
return unless @a == @b;
missing here which I accidentally deleted before posting ...
------------------------------
Date: Thu, 04 Jun 2015 06:08:18 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Comparing Lists
Message-Id: <mkoivi$32h$1@speranza.aioe.org>
El 03/06/15 a las 15:53, Ted Zlatanov escribió:
> On Thu, 28 May 2015 14:10:32 -0700 (PDT) "C.DeRykus" <derykus@gmail.com> wrote:
>
>>> Is there a simpler, more-direct way to do list comparisons?
>
> CD> Assuming no binary data or memory-busting lists:
>
> CD> say "same" if join("\0",@list1) eq join("\0",@list2);
>
> Even disregarding the inefficiency, it's annoying to get warnings about
> undefined values, and of course, you probably don't want to treat "" the
> same as undef... which converting it to a string will do.
>
> Here's a simple version, lightly tested.
>
> Ted
>
> #+begin_src perl
> sub differ
> {
> my @list1 = (undef,2,3);
> my @list2 = (undef,2);
>
> return 1 if scalar @list1 != scalar @list2;
>
> my $differ = 0;
> while (scalar @list1)
> {
> my $x = pop @list1;
> my $y = pop @list2;
>
> # xor
> return 1 if (defined $x && !defined $y) || (!defined $x && defined $y);
>
> # because of the above, we now know $x and $y are either both defined
> # or both undefined (the latter case makes them equal)
>
> return 1 if (defined $x && defined $y) && ($x ne $y); # note this assumes you want string equality
> }
>
> return 0;
> }
> #+end_src
>
Inspired in your version, here's another with other style:
#!/usr/bin/perl
use strict;
use warnings;
my @a = (1, ,2, 10, undef, "", '-0', undef);
my @b = (1,,02, 1e1, undef, "", '-0', "");
if (compare(\@a, \@b)){
print "ok\n";
}else{
print "not ok\n";
}
my @c= ( 99999999999999999999999999999.0 , 0xf);
my @d= ( 99999999999999999999999999999.01, 15 );
if (compare(\@c, \@d)){
print "OK\n";
}else{
print "NOT OK\n";
}
sub compare {
my ($x, $y) = @_;
no warnings;
my $len = scalar @$x;
if ($len != scalar @$y) { return 0; }
my @X = @$x;
my @Y = @$y;
for (0..$len-1){
return 0 unless ( ($X[$_] == $Y[$_]) || ($X[$_] eq $Y[$_]) );
return 0 unless ( defined ($X[$_]) == defined ($Y[$_]) );
}
return 1;
}
Salutations.
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Thu, 04 Jun 2015 06:42:28 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <87d21bkb57.fsf@lifelogs.com>
On Thu, 04 Jun 2015 06:08:18 +0200 gamo <gamo@telecable.es> wrote:
g> Inspired in your version, here's another with other style:
...
g> sub compare {
g> my ($x, $y) = @_;
g> no warnings;
g> my $len = scalar @$x;
g> if ($len != scalar @$y) { return 0; }
g> my @X = @$x;
g> my @Y = @$y;
g> for (0..$len-1){
g> return 0 unless ( ($X[$_] == $Y[$_]) || ($X[$_] eq $Y[$_]) );
g> return 0 unless ( defined ($X[$_]) == defined ($Y[$_]) );
g> }
g> return 1;
g> }
Cool. My version was destructive, a habit I've picked up from Lisp.
This is better.
But your version should check for `defined` first. Shutting up warnings
is, IMHO, almost always a bad thing (I'd rather write more code or even
restructure than ignore warnings). In this case, it's a trivial change
and suddenly it's not needed.
Ted
------------------------------
Date: Thu, 04 Jun 2015 06:55:16 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <878ubzkajv.fsf@lifelogs.com>
On Wed, 03 Jun 2015 21:54:03 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Wed, 3 Jun 2015 10:15:00 -0700 (PDT) "C.DeRykus" <derykus@gmail.com> wrote:
CD> Of course with no "memory-busting lists", efficiency may not be
CD> concerning; undef warnings easily quashed; and "" treated same as
CD> undef a non-factor.
>>
CD> Or not...
>>
>> I think a correct efficient solution is strictly more useful, so I'll
>> just point to List::Compare on CPAN now.
RW> "I believe something which can be downloaded for free from ... also
RW> solves the problem" doesn't really answer the original question,
RW> especially not without at least showing an example of how it's supposed
RW> to be used (in this case, it would need just about as much code to be
RW> written as a direct comparison routine in order to execute some part
RW> of hundreds of lines of code hidden in the module).
I thought I answered the original question already with practical code.
List::Compare is much more powerful, providing commonly needed tools
like set difference and intersection. IMO it's well worth the "free
download" for that. But more importantly, it's *correct* and *efficient*
whereas the ridiculously inefficient join/pack solutions weren't. You
can always do better than the CPAN modules in some ways, e.g. you can be
more efficient than List::Compare if you know your data is sorted or
write in assembler. The tradeoff is in the hours you'll spend
developing, debugging, and maintaining such code.
RW> Also, there is really no 'correct' way to compare two lists in Perl
RW> as the choice of ==/ != vs eq/ ne vs 'something completely
RW> different', eg $a - $b < 0.0001 for comparing floating point numbers
RW> and whether or not undef needs to be handled and how it is supposed
RW> to be handled depends on the situation.
Well, of course. Which is another reason the join/pack solutions were
simply wrong, because they can't easily be fixed to support anything but
string equality (and no, rewriting the lists before join/pack is not a
solution).
RW> Eg, a subroutine which expects references to two arrays whose elements
RW> can be compared via eq/ne but which avoids uninitialized value warnings
RW> and distinguishes between undef and an empty string, testing the 'lists'
RW> for equality, could look like this:
RW> sub zl_eq
RW> {
RW> local (*a, *b) = @_;
RW> defined($a[$_]) ? defined($b[$_]) && $a[$_] eq $b[$_] : !defined($b[$_]) or return
RW> for 0 .. $#a;
RW> return 1;
RW> }
I'm glad you've contributed a working solution, but this is
unnecessarily complex IMO:
* all the code in one line
* doesn't return early if the list sizes differ
* no parenthesis around the logic, plus the ?: operator, is at best
confusing and probably misleading
I'd rather see my version (rewritten with references, as gamo showed) in
production code than yours. But I'd rather see List::Compare than
either of them, personally.
Ted
------------------------------
Date: Thu, 04 Jun 2015 07:43:55 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <874mmnk8as.fsf@lifelogs.com>
On Thu, 04 Jun 2015 06:42:28 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote:
TZ> On Thu, 04 Jun 2015 06:08:18 +0200 gamo <gamo@telecable.es> wrote:
g> my @X = @$x;
g> my @Y = @$y;
TZ> Cool. My version was destructive, a habit I've picked up from Lisp.
TZ> This is better.
I missed this before: making copies of the original lists is not
necessary here and will kill performance.
Ted
------------------------------
Date: Thu, 04 Jun 2015 07:44:22 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <87zj4fitpl.fsf@lifelogs.com>
On Thu, 04 Jun 2015 06:55:16 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote:
TZ> * doesn't return early if the list sizes differ
Strike that; I didn't see your followup.
Ted
------------------------------
Date: Thu, 04 Jun 2015 15:18:25 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87bngvpnf2.fsf@doppelsaurus.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Wed, 03 Jun 2015 21:54:03 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> RW> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> On Wed, 3 Jun 2015 10:15:00 -0700 (PDT) "C.DeRykus" <derykus@gmail.com> wrote:
> CD> Of course with no "memory-busting lists", efficiency may not be
> CD> concerning; undef warnings easily quashed; and "" treated same as
> CD> undef a non-factor.
>>>
> CD> Or not...
>>>
>>> I think a correct efficient solution is strictly more useful, so I'll
>>> just point to List::Compare on CPAN now.
>
> RW> "I believe something which can be downloaded for free from ... also
> RW> solves the problem" doesn't really answer the original question,
> RW> especially not without at least showing an example of how it's supposed
> RW> to be used (in this case, it would need just about as much code to be
> RW> written as a direct comparison routine in order to execute some part
> RW> of hundreds of lines of code hidden in the module).
>
> I thought I answered the original question already with practical code.
>
> List::Compare is much more powerful,
It's the usual hodge-podge of everything that's losely related to 'list
comparisons' people who enjoy making something more complicated until
the point where they realized they don't understand it anymore (which is
usually way later than this actually happening) tend to come up with over
the course of a dozen years or so.
In fact, as far as I could determine, it doesn't even offer 'list
comparisons' out of the box because it really doesn't operate on 'lists'
(ordered sets) but on unordered sets. It's possible to disable automatic
sorting of lists and then do an equivalence test.
NB: The documentation of this module is as rambling as the code which
means this may be entirely wrong but I already spent more time reading
through it than implementing, testing and debugging ten list comparison
routines would have taken.
[...]
> RW> Also, there is really no 'correct' way to compare two lists in Perl
> RW> as the choice of ==/ != vs eq/ ne vs 'something completely
> RW> different', eg $a - $b < 0.0001 for comparing floating point numbers
> RW> and whether or not undef needs to be handled and how it is supposed
> RW> to be handled depends on the situation.
>
> Well, of course. Which is another reason the join/pack solutions were
> simply wrong, because they can't easily be fixed to support anything but
> string equality (and no, rewriting the lists before join/pack is not a
> solution).
'join/ pack' was actually the right approach for the problem in
question. More generally, instead of comparing two lists, one can create
a suitable, unambigious serialization of the data and compare the
result. This is theoretically inefficient as it requires traversing both
lists completely prior to doing anything useful, however, I didn't do
any actual tests and in case performance doesn't matter that much (which
it likely doesn't) it has certainly something going for it as quickly
written and easily understandable solution, especially if it can be
accomplished with readily available perl features instead of requiring
thousands of lines of third party code conveniently stashed away in
place where it's easy to pretend that it doesn't exist.
> RW> Eg, a subroutine which expects references to two arrays whose elements
> RW> can be compared via eq/ne but which avoids uninitialized value warnings
> RW> and distinguishes between undef and an empty string, testing the 'lists'
> RW> for equality, could look like this:
>
> RW> sub zl_eq
> RW> {
> RW> local (*a, *b) = @_;
>
> RW> defined($a[$_]) ? defined($b[$_]) && $a[$_] eq $b[$_] : !defined($b[$_]) or return
> RW> for 0 .. $#a;
>
> RW> return 1;
> RW> }
>
> I'm glad you've contributed a working solution, but this is
> unnecessarily complex IMO:
>
> * all the code in one line
That's a formatting isse which doesn't change the complexity of the
actual code.
[...]
> * no parenthesis around the logic, plus the ?: operator, is at best
> confusing and probably misleading
This is evaluated exactly has one would suppose ?: to work: Depending on
the initial test, either the left-hand or right-hand side of the :
counts. Operator precedence can be checked quickly by looking it up in
the docs or by running the code through B::Deparse.
------------------------------
Date: Thu, 04 Jun 2015 10:47:38 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <87oakvmsxh.fsf@lifelogs.com>
On Thu, 04 Jun 2015 15:18:25 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> In fact, as far as I could determine, [List::Compare] doesn't even offer 'list
RW> comparisons' out of the box because it really doesn't operate on 'lists'
RW> (ordered sets) but on unordered sets. It's possible to disable automatic
RW> sorting of lists and then do an equivalence test.
It offers a fast boolean list comparison without sorting (-a -u IIRC).
RW> 'join/ pack' was actually the right approach for the problem in
RW> question.
The problem, as given: "I need to compare two lists item-for-item"
As I explained already, join/pack is the wrong approach because 1) undef
and "" are not the same thing; and 2) it's inefficient. This is basic
stuff, usually taught in first-year algorithms courses.
It may work for you, and that's great. But presenting it in a
programming forum such as c.l.p.misc implies more than that.
RW> More generally, instead of comparing two lists, one can create a
RW> suitable, unambigious serialization of the data and compare the
RW> result.
You can also write a letter to Jerusalem and ask a priest to compare the
two lists. That's also a general solution and just as misguided.
>> * no parenthesis around the logic, plus the ?: operator, is at best
>> confusing and probably misleading
RW> This is evaluated exactly has one would suppose ?: to work: Depending on
RW> the initial test, either the left-hand or right-hand side of the :
RW> counts. Operator precedence can be checked quickly by looking it up in
RW> the docs or by running the code through B::Deparse.
I said "confusing and probably misleading." Don't force the code reader
to think about operator precedence.
Ted
------------------------------
Date: Thu, 04 Jun 2015 16:06:37 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87y4jzo6ma.fsf@doppelsaurus.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 04 Jun 2015 15:18:25 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
> RW> In fact, as far as I could determine, [List::Compare] doesn't even offer 'list
> RW> comparisons' out of the box because it really doesn't operate on 'lists'
> RW> (ordered sets) but on unordered sets. It's possible to disable automatic
> RW> sorting of lists and then do an equivalence test.
>
> It offers a fast boolean list comparison without sorting (-a -u IIRC).
As an afterthought, the author added this option at some point in time.
> RW> 'join/ pack' was actually the right approach for the problem in
> RW> question.
>
> The problem, as given: "I need to compare two lists item-for-item"
No. The problem was "I want to make an educated guess at the file type
of a certain file by inspecting parts of the content to look for a
certain sequence of bytes". The idea to turn the byte strings into lists
of numbers and compare the numbers was just an initial approach.
> As I explained already, join/pack is the wrong approach because 1) undef
> and "" are not the same thing; and 2) it's inefficient. This is basic
> stuff, usually taught in first-year algorithms courses.
As I wrote already:
,----
| instead of comparing two lists, one can create a suitable,
| unambigious serialization of the data and compare the
| result. This is theoretically inefficient as it requires
| traversing both lists completely prior to doing anything useful,
| however, I didn't do any actual tests and in case performance
| doesn't matter that much (which it likely doesn't) it has
| certainly something going for it as quickly written and easily
| understandable solution
`----
> It may work for you, and that's great. But presenting it in a
> programming forum such as c.l.p.misc implies more than that.
... which means it will work in some cases and not work in some others
and it is certainly worthwhile to be aware of this approach for solving
'a comparison problem'. As to the 'inefficiency', some actual numbers
would be interesting, although chances are that the difference doesn't
really matter.
[...]
>>> * no parenthesis around the logic, plus the ?: operator, is at best
>>> confusing and probably misleading
>
> RW> This is evaluated exactly has one would suppose ?: to work: Depending on
> RW> the initial test, either the left-hand or right-hand side of the :
> RW> counts. Operator precedence can be checked quickly by looking it up in
> RW> the docs or by running the code through B::Deparse.
>
> I said "confusing and probably misleading." Don't force the code reader
> to think about operator precedence.
This would be more suitably addressed to the person who invented/
implemented 'operator precedence'. If 'the code reader' doesn't want to
be bothered with that, he should restrict himself to reading code written
in languages which don't employ it. Also, there is really no reason to
think about it as it just works out in the naturally expected way.
------------------------------
Date: Thu, 04 Jun 2015 11:20:56 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Comparing Lists
Message-Id: <87k2vjmrdz.fsf@lifelogs.com>
On Thu, 04 Jun 2015 16:06:37 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
RW> If 'the code reader' doesn't want to be bothered with [operator
RW> precedence], he should restrict himself to reading code written in
RW> languages which don't employ it.
I hope, by the same logic, that you'll stop reading posts in c.l.p.misc
because they deal with programming.
Ted
------------------------------
Date: Thu, 04 Jun 2015 17:34:51 +0200
From: gamo <gamo@telecable.es>
Subject: Re: Comparing Lists
Message-Id: <mkpr6q$vcs$1@speranza.aioe.org>
El 04/06/15 a las 13:43, Ted Zlatanov escribió:
> On Thu, 04 Jun 2015 06:42:28 -0400 Ted Zlatanov <tzz@lifelogs.com> wrote:
>
> TZ> On Thu, 04 Jun 2015 06:08:18 +0200 gamo <gamo@telecable.es> wrote:
> g> my @X = @$x;
> g> my @Y = @$y;
>
> TZ> Cool. My version was destructive, a habit I've picked up from Lisp.
> TZ> This is better.
>
> I missed this before: making copies of the original lists is not
> necessary here and will kill performance.
>
> Ted
>
You can avoid the copy using prototypes. That seems not a big deal.
sub compare (@@) {
;
}
Other workaround could be to $X = pop @$x; etc. inside the for()
--
http://www.telecable.es/personales/gamo/
The generation of random numbers is too important to be left to chance
------------------------------
Date: Thu, 04 Jun 2015 16:40:09 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87pp5bo52e.fsf@doppelsaurus.mobileactivedefense.com>
Ted Zlatanov <tzz@lifelogs.com> writes:
> On Thu, 04 Jun 2015 16:06:37 +0100 Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
> RW> If 'the code reader' doesn't want to be bothered with [operator
> RW> precedence], he should restrict himself to reading code written in
> RW> languages which don't employ it.
>
> I hope, by the same logic, that you'll stop reading posts in c.l.p.misc
> because they deal with programming.
As you've astutely noticed, this is a public forum and this means that
you will have to live with the fact that not everybody agrees with any
particular opinion you might happen to have. Eg, for the shrunken case
in question, I agree with the notion that the convenience benefits
'operator precedence' outweigh the drawback of a (IMHO marginally)
higher learning curve, especially as the learning curve can't be
avoided: The feature exists. Hence, someone who wants to be able to work
with the language has to be able to cope with it being used.
------------------------------
Date: Thu, 04 Jun 2015 11:50:07 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Comparing Lists
Message-Id: <87r3pr3234.fsf@stemsystems.com>
>>>>> "g" == gamo <gamo@telecable.es> writes:
g> my @c= ( 99999999999999999999999999999.0 , 0xf);
g> my @d= ( 99999999999999999999999999999.01, 15 );
never compare floats directly (except for 0).
g> sub compare {
g> my ($x, $y) = @_;
g> no warnings;
g> my $len = scalar @$x;
g> if ($len != scalar @$y) { return 0; }
why need $len? no need for scalar() either as those are in scalar context
g> my @X = @$x;
g> my @Y = @$y;
why the copying? you don't modify the arrays
g> for (0..$len-1){
use a named var and not $_ when you can.
g> return 0 unless ( ($X[$_] == $Y[$_]) || ($X[$_] eq $Y[$_]) );
don't do both compare types. you will get warnings if the == sees
non-numbers.
g> return 0 unless ( defined ($X[$_]) == defined ($Y[$_]) );
that doesn't make any sense. what if one entry was defined as '' and the
other undef? those aren't equal but your code makes them so.
the module method works and is the best way to do this unless you have
known data restrictions or such.
uri
------------------------------
Date: Thu, 04 Jun 2015 17:28:58 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Comparing Lists
Message-Id: <87lhfzo2t1.fsf@doppelsaurus.mobileactivedefense.com>
gamo <gamo@telecable.es> writes:
> El 03/06/15 a las 15:53, Ted Zlatanov escribió:
>> On Thu, 28 May 2015 14:10:32 -0700 (PDT) "C.DeRykus" <derykus@gmail.com> wrote:
>>
>>>> Is there a simpler, more-direct way to do list comparisons?
[...]
> sub compare {
> my ($x, $y) = @_;
> no warnings;
> my $len = scalar @$x;
> if ($len != scalar @$y) { return 0; }
> my @X = @$x;
> my @Y = @$y;
> for (0..$len-1){
> return 0 unless ( ($X[$_] == $Y[$_]) || ($X[$_] eq $Y[$_]) );
> return 0 unless ( defined ($X[$_]) == defined ($Y[$_]) );
> }
> return 1;
> }
Caching the result of an indirect lookup is likely to have speed
advantages in C where 'local variables' can end up being registers and
compilers usually generated repeated loads for repeated indirect
accesses, however, things are different in Perl: A scalar my variable is
decidedly not 'in a register' and getting the length or the maximum
index out of an array is not necessarily more complex than getting a
scalar value from any other location.
-----
use Benchmark;
my @a = qw(a b c d e);
sub cached
{
my $a = $_[0];
my $len;
$len = @$a;
return if $len > 10;
$n = 0;
++$n for 0 .. $len - 1;
}
sub direct
{
my $a = $_[0];
return if @$a > 10;
$n = 0;
++$n for 0 .. $#$a;
}
timethese(-5,
{
cached => sub {
cached(\@a);
},
direct => sub {
direct(\@a);
}});
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4445
***************************************
