[11361] in Perl-Users-Digest
Perl-Users Digest, Issue: 4962 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Feb 26 11:19:45 1999
Date: Fri, 26 Feb 99 08:15:30 -0800
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 26 Feb 1999 Volume: 8 Number: 4962
Today's topics:
Re: change column of nmbers to 2 dim array (Randal L. Schwartz)
Re: change column of nmbers to 2 dim array <uri@ibnets.com>
Re: change column of nmbers to 2 dim array (Bart Lateur)
Re: change column of nmbers to 2 dim array <dgris@moiraine.dimensional.com>
Re: change column of nmbers to 2 dim array (Bart Lateur)
Re: change column of nmbers to 2 dim array (Abigail)
Re: change column of nmbers to 2 dim array (Ronald J Kimball)
Re: change column of nmbers to 2 dim array (Ronald J Kimball)
Re: change column of nmbers to 2 dim array (Abigail)
Re: change column of nmbers to 2 dim array (Ronald J Kimball)
Re: change column of nmbers to 2 dim array (Bart Lateur)
Re: change column of nmbers to 2 dim array (Bart Lateur)
Re: change column of nmbers to 2 dim array (Abigail)
Re: change column of nmbers to 2 dim array (Abigail)
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 23 Feb 1999 11:05:02 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <m1u2wdndpd.fsf@halfdome.holdit.com>
>>>>> "Bart" == Bart Lateur <bart.lateur@skynet.be> writes:
Bart> My point is the foreach() is garanteed to process the list elements in
Bart> order, so side effects in foreach() are not considered bad. On the
Bart> contrary: foreach() without side efeects is useless.
Bart> OTOH map() is designed to be used without side effects.
But map is *also* guaranteed to go in order. At least, P5P would say so.
And the code certainly *does* process it in order.
I don't know where you got the impression that foreach definitely goes
in order but map might not. Nothing I've read or written implies
that. Please stop with this nonsense! In fact, quite a few snippet
idioms require correct order, and would break otherwise, so P5P could
not in their right collective mind change that now.
print "Just another Perl hacker,"
--
Name: Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
Keywords: Perl training, UNIX[tm] consulting, video production, skiing, flying
Email: <merlyn@stonehenge.com> Snail: (Call) PGP-Key: (finger merlyn@teleport.com)
Web: <A HREF="http://www.stonehenge.com/merlyn/">My Home Page!</A>
Quote: "I'm telling you, if I could have five lines in my .sig, I would!" -- me
------------------------------
Date: 23 Feb 1999 13:04:06 -0500
From: Uri Guttman <uri@ibnets.com>
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <394sodq9nt.fsf@ibnets.com>
>>>>> "BL" == Bart Lateur <bart.lateur@skynet.be> writes:
>> So, the Schwartzian Transform is wrong?
BL> No. The Schwartzian Transform does not depend on a particular
BL> execution order for the elements. It merely converts elements of a
BL> list (but without even changing the elements themselves) into a
BL> different representation, sort on that, and then extract the
BL> original data again.
wrong. the extract map in the ST has to keep the data in the sorted
order. you sort the anon lists and the derefs done by map can't change
the order or you lose the sort order. map's origin from lisp is that the
list order is kept. as in lisp, you have access to the original values
(as in foreach) via aliasing $_. lisp used it as a way to apply an
operation or func to each element of a list without writing a loop. they
used both the order keeping and the side effect nature of map.
the perl community seems to have a majority that thinks that map in a
void context is bad, since that means only side effects were doen and
foreach is clearer for that. in lisp there was no better choice so that
form of map was cool, in perl foreach does seem clearer to most for side
effect code.
so my conclusion is that for better style (but not for religious
reasons) side effects on the original data in map are to avoided. i have
done maps which did other side effects as well as returned a new list
but i didn't modify the original list. that gets to be a little gray in
style.
uri
--
Uri Guttman Hacking Perl for Ironbridge Networks
uri@sysarch.com uri@ironbridgenetworks.com
------------------------------
Date: Tue, 23 Feb 1999 20:11:13 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <36d30b3e.657891@news.skynet.be>
Randal L. Schwartz wrote:
>I don't know where you got the impression that foreach definitely goes
>in order but map might not. Nothing I've read or written implies
>that. Please stop with this nonsense!
Just document it in perlfunc, and I'll shut up.
Bart.
------------------------------
Date: 23 Feb 1999 15:34:06 -0700
From: Daniel Grisinger <dgris@moiraine.dimensional.com>
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <m3iucsda1t.fsf@moiraine.dimensional.com>
bart.lateur@skynet.be (Bart Lateur) writes:
> Just document it in perlfunc, and I'll shut up.
Patches are always welcome. Read Porting/patching.pod in
your source distribution if you need instructions on how
to prepare your patch.
dgris
--
Daniel Grisinger dgris@moiraine.dimensional.com
perl -Mre=eval -e'$_=shift;;@[=split//;;$,=qq;\n;;;print
m;(.{$-}(?{$-++}));,q;;while$-<=@[;;' 'Just Another Perl Hacker'
------------------------------
Date: Tue, 23 Feb 1999 15:47:57 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <36d2c3ac.5508373@news.skynet.be>
[Sorry for the late reply, but last week was extremely busy.]
Abigail wrote:
>Bart Lateur (bart.lateur@skynet.be) wrote on MCMXCI September MCMXCIII:
>,, Abigail wrote:
>,,
>,, >Who says map changing the elements of the list it iterates over has
>,, >something to do with using it in void context?
>,, >
>,, >In fact, map is an operation heavily used in functional languages.
>,, >Functional languages have a tendency to be side effect free as well.
>,,
>,, So using map in order to have side effects is bad form?
>
>*I* am not the person claiming things are bad form. Ask Randal.
But *you* like map(), and *you* like it's functional origin. It's the
functional programming people who'd consider it bad form if there are
side effects.
>,, Tell me, what use would the next code be, except to waste
>,, cycles?
>,,
>,, map { $_.$_ } LIST;
>
>Just as useful as
>
> foreach (LIST) {$_ . $_}
>
>What's your point?
My point is the foreach() is garanteed to process the list elements in
order, so side effects in foreach() are not considered bad. On the
contrary: foreach() without side efeects is useless.
OTOH map() is designed to be used without side effects.
It's merely a readablity rule:
map() => function (list -> list), no side effects
foreach() => execution order, side effects (incl printing).
>,, "map" is a looping construct. But to stay absolutely clean, you may not
>,, depend on it being executed in sequence. So the next is bad form too:
>,,
>,, my $i = 0;
>,, %map = map { $_ => $i++ } @ary;
>
>So, you are claiming that
>
> @squares = map {$i * $i} 1 .. 10;
>
>isn't garanteed to produce the first 10 squares in order? Are you sure?
I'm very sure. The results will depend on what the initial value for $i
was, but you'll get an array with 10 times the same value. :-)
But, I catch your drift. You must have ment
$i = 1;
@squares = map {$i * $i++} 1 .. 10;
which is unnecessary, as this will be good enough, and uses map() as it
was intended:
@squares = map {$_ * $_} 1 .. 10;
If in your approach, people want the squares of numbers 11 though 20,
they might change the code to:
@squares = map {$i * $i++} 11 .. 20;
but the results will not reflect this change.
>Can you give me any references that this isn't garanteen?
It's not in the specs.
> map BLOCK LIST
> Evaluates the BLOCK or EXPR for each element of LIST
> (locally setting $_ to each element) and returns the
> list value composed of the results of each such
> evaluation.
There is NOTHING there about execution order. ONLY about "once for every
item", and that the results will be stacked. And, but this will be just
me, it reads as if "$_" is intended as a "read-only" value.
>Oh, really? Then tell, what can we use map {} for?
To build a list of function results, starting from a list of parameters.
Nothing more, nothing less.
Instead of just blowing bubbles, I'll give you some demo code.
Most people (probably including you) seem to think of map as:
sub map2 (&@);
($\,$,) = ("\n"," ");
print "built-in:", map { $_ => ord } ('A' .. 'D');
print "forward: ", map2 { $_ => ord } ('A' .. 'D');
sub map2 (&@) {
my $func = shift;
my @result;
foreach (@_) {
push @result, $func->();
}
return wantarray?@result:$result[-1];
}
__END__
built-in: A 65 B 66 C 67 D 68
forward: A 65 B 66 C 67 D 68
So map2 *uses* foreach. But, map in a void context looks like it first
builds that list, and then we simply throw it away.
But as I understand the specs, this is an equally valied implementation:
sub map3 (&@);
($\,$,) = ("\n"," ");
print "built-in:", map { $_ => ord } ('A' .. 'D');
print "reverse: ", map3 { $_ => ord } ('A' .. 'D');
sub map3 (&@) {
my $func = shift;
my @result;
foreach (reverse @_) {
unshift @result, $func->();
}
return wantarray?@result:$result[-1];
}
__END__
built-in: A 65 B 66 C 67 D 68
reverse: A 65 B 66 C 67 D 68
Now, using side effects:
($\,$,) = ("\n"," ");
print '"Clean":';
print "built-in:", map { $_ => ord } ('A' .. 'D');
print "forward: ", map2 { $_ => ord } ('A' .. 'D');
print "reverse: ", map3 { $_ => ord } ('A' .. 'D');
print "\nWith side effects:";
my $i;
$i=0; print "built-in:", map { $_ => ++$i } ('A' .. 'D');
$i=0; print "forward: ", map2 { $_ => ++$i } ('A' .. 'D');
$i=0; print "reverse: ", map3 { $_ => ++$i } ('A' .. 'D');
__END__
"Clean":
built-in: A 65 B 66 C 67 D 68
forward: A 65 B 66 C 67 D 68
reverse: A 65 B 66 C 67 D 68
With side effects:
built-in: A 1 B 2 C 3 D 4
forward: A 1 B 2 C 3 D 4
reverse: A 4 B 3 C 2 D 1
I say that you're using things in bad form if your code gives different
results for map2 and for map3.
>\\ "map" is a looping construct. But to stay absolutely clean, you may not
>\\ depend on it being executed in sequence.
>
>So, the Schwartzian Transform is wrong?
No. The Schwartzian Transform does not depend on a particular execution
order for the elements. It merely converts elements of a list (but
without even changing the elements themselves) into a different
representation, sort on that, and then extract the original data again.
If you simply plug in map3 instead of map, the S.T. will give the same
results.
Bart.
------------------------------
Date: 24 Feb 1999 00:31:43 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <7avh9f$ao5$1@client2.news.psi.net>
Bart Lateur (bart.lateur@skynet.be) wrote on MMII September MCMXCIII in
<URL:news:36d2c3ac.5508373@news.skynet.be>:
?? [Sorry for the late reply, but last week was extremely busy.]
??
?? Abigail wrote:
??
?? >Bart Lateur (bart.lateur@skynet.be) wrote on MCMXCI September MCMXCIII:
??
?? >,, Abigail wrote:
?? >,,
?? >,, >Who says map changing the elements of the list it iterates over has
?? >,, >something to do with using it in void context?
?? >,, >
?? >,, >In fact, map is an operation heavily used in functional languages.
?? >,, >Functional languages have a tendency to be side effect free as well.
?? >,,
?? >,, So using map in order to have side effects is bad form?
?? >
?? >*I* am not the person claiming things are bad form. Ask Randal.
??
?? But *you* like map(), and *you* like it's functional origin. It's the
?? functional programming people who'd consider it bad form if there are
?? side effects.
There are no side effects in pure functional languages. But a statement
that's side effect free in Perl is very useless. Up to the point it
might even trigger warnings.
My point still stands. What has map {} in a void context to do with
changing the elements of a list over which it iterates? I can as easily
change the elements of a list in void context, as in scalar or list
context. And I can have useful maps in void context that do not change
the elements of the list. Void context and changing the elements of the
list over which the map iterates are separate issues.
?? >,, Tell me, what use would the next code be, except to waste
?? >,, cycles?
?? >,,
?? >,, map { $_.$_ } LIST;
?? >
?? >Just as useful as
?? >
?? > foreach (LIST) {$_ . $_}
?? >
?? >What's your point?
??
?? My point is the foreach() is garanteed to process the list elements in
?? order, so side effects in foreach() are not considered bad. On the
?? contrary: foreach() without side efeects is useless.
??
?? OTOH map() is designed to be used without side effects.
Ah, so map wasn't designed such that you could do
@foo = map {$_ * $_} 1 .. 10;
? Side-effect free statements in Perl are pretty useless.
?? It's merely a readablity rule:
?? map() => function (list -> list), no side effects
?? foreach() => execution order, side effects (incl printing).
??
?? >,, "map" is a looping construct. But to stay absolutely clean, you may not
?? >,, depend on it being executed in sequence. So the next is bad form too:
?? >,,
?? >,, my $i = 0;
?? >,, %map = map { $_ => $i++ } @ary;
?? >
?? >So, you are claiming that
?? >
?? > @squares = map {$i * $i} 1 .. 10;
?? >
?? >isn't garanteed to produce the first 10 squares in order? Are you sure?
??
?? I'm very sure. The results will depend on what the initial value for $i
?? was, but you'll get an array with 10 times the same value. :-)
??
?? But, I catch your drift. You must have ment
??
?? $i = 1;
?? @squares = map {$i * $i++} 1 .. 10;
No, I meant
@squares = map {$_ * $_} 1 .. 10;
??
?? which is unnecessary, as this will be good enough, and uses map() as it
?? was intended:
??
?? @squares = map {$_ * $_} 1 .. 10;
You're claiming it isn't. That it could produce the list
(64, 25, 81, 16, 36, 1, 100, 4, 9, 49)
instead.
??
?? If in your approach, people want the squares of numbers 11 though 20,
?? they might change the code to:
??
?? @squares = map {$i * $i++} 11 .. 20;
??
?? but the results will not reflect this change.
??
?? >Can you give me any references that this isn't garanteen?
??
?? It's not in the specs.
??
?? > map BLOCK LIST
??
?? > Evaluates the BLOCK or EXPR for each element of LIST
?? > (locally setting $_ to each element) and returns the
?? > list value composed of the results of each such
?? > evaluation.
??
?? There is NOTHING there about execution order. ONLY about "once for every
?? item", and that the results will be stacked. And, but this will be just
?? me, it reads as if "$_" is intended as a "read-only" value.
It's treating $_ as, surprise, surprise, foreach does.
BTW, it doesn't say anything about shuffling the order either.
?? >Oh, really? Then tell, what can we use map {} for?
??
?? To build a list of function results, starting from a list of parameters.
?? Nothing more, nothing less.
But without knowing the order. And the random order gives us what benefits?
?? Instead of just blowing bubbles, I'll give you some demo code.
??
?? Most people (probably including you) seem to think of map as:
??
?? sub map2 (&@);
?? ($\,$,) = ("\n"," ");
?? print "built-in:", map { $_ => ord } ('A' .. 'D');
?? print "forward: ", map2 { $_ => ord } ('A' .. 'D');
?? sub map2 (&@) {
?? my $func = shift;
?? my @result;
?? foreach (@_) {
?? push @result, $func->();
?? }
?? return wantarray?@result:$result[-1];
?? }
?? __END__
?? built-in: A 65 B 66 C 67 D 68
?? forward: A 65 B 66 C 67 D 68
??
?? So map2 *uses* foreach. But, map in a void context looks like it first
?? builds that list, and then we simply throw it away.
It doesn't look to me it does. Not that maps in void context have anything
to do with your examples.
?? But as I understand the specs, this is an equally valied implementation:
What specs are you talking about? I hope not 'man perlfunc'. I don't
think that makes a claim to be the specification of Perl. At best,
it will *describe* what Perl does. Not specify.
?? sub map3 (&@);
?? ($\,$,) = ("\n"," ");
?? print "built-in:", map { $_ => ord } ('A' .. 'D');
?? print "reverse: ", map3 { $_ => ord } ('A' .. 'D');
?? sub map3 (&@) {
?? my $func = shift;
?? my @result;
?? foreach (reverse @_) {
?? unshift @result, $func->();
?? }
?? return wantarray?@result:$result[-1];
?? }
?? __END__
?? built-in: A 65 B 66 C 67 D 68
?? reverse: A 65 B 66 C 67 D 68
??
?? Now, using side effects:
??
?? ($\,$,) = ("\n"," ");
?? print '"Clean":';
?? print "built-in:", map { $_ => ord } ('A' .. 'D');
?? print "forward: ", map2 { $_ => ord } ('A' .. 'D');
?? print "reverse: ", map3 { $_ => ord } ('A' .. 'D');
??
?? print "\nWith side effects:";
?? my $i;
?? $i=0; print "built-in:", map { $_ => ++$i } ('A' .. 'D');
?? $i=0; print "forward: ", map2 { $_ => ++$i } ('A' .. 'D');
?? $i=0; print "reverse: ", map3 { $_ => ++$i } ('A' .. 'D');
?? __END__
?? "Clean":
?? built-in: A 65 B 66 C 67 D 68
?? forward: A 65 B 66 C 67 D 68
?? reverse: A 65 B 66 C 67 D 68
??
?? With side effects:
?? built-in: A 1 B 2 C 3 D 4
?? forward: A 1 B 2 C 3 D 4
?? reverse: A 4 B 3 C 2 D 1
??
?? I say that you're using things in bad form if your code gives different
?? results for map2 and for map3.
Well, fix map3 then.
??
?? >\\ "map" is a looping construct. But to stay absolutely clean, you may not
?? >\\ depend on it being executed in sequence.
?? >
?? >So, the Schwartzian Transform is wrong?
??
?? No. The Schwartzian Transform does not depend on a particular execution
?? order for the elements.
Oh, it most certainly does if you want to make a stable sort.
?? It merely converts elements of a list (but
?? without even changing the elements themselves) into a different
?? representation, sort on that, and then extract the original data again.
?? If you simply plug in map3 instead of map, the S.T. will give the same
?? results.
#!/usr/local/bin/perl -w
use strict;
sub map3 (&@) {
my $func = shift;
my @result;
foreach (reverse @_) {
unshift @result, $func->();
}
return wantarray?@result:$result[-1];
}
# Letters added to show the effect of a stable sort.
my @unsorted = qw (10a 8b 6c 10d 2e 8f 9g 7h 6i 3j 1k);
my $i = 0;
my @map_sorted = map {$_ -> [0]}
sort {$a -> [1] <=> $b -> [1] ||
$a -> [2] <=> $b -> [2]}
map {[$_, /(\d+)/, $i ++]} @unsorted;
$i = 0;
my @map3_sorted = map3 {$_ -> [0]}
sort {$a -> [1] <=> $b -> [1] ||
$a -> [2] <=> $b -> [2]}
map3 {[$_, /(\d+)/, $i ++]} @unsorted;
print "@map_sorted\n";
print "@map3_sorted\n";
__END__
1k 2e 3j 6c 6i 7h 8b 8f 9g 10a 10d
1k 2e 3j 6i 6c 7h 8f 8b 9g 10d 10a
They are sorted differently. I'd call map3 broken.
Abigail
--
sub f{sprintf'%c%s',$_[0],$_[1]}print f(74,f(117,f(115,f(116,f(32,f(97,
f(110,f(111,f(116,f(104,f(0x65,f(114,f(32,f(80,f(101,f(114,f(0x6c,f(32,
f(0x48,f(97,f(99,f(107,f(101,f(114,f(10,q ff)))))))))))))))))))))))))
------------------------------
Date: Tue, 23 Feb 1999 20:59:02 -0500
From: rjk@linguist.dartmouth.edu (Ronald J Kimball)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <1dnp4id.1g75ttz14bmiq6N@bay1-193.quincy.ziplink.net>
Uri Guttman <uri@ibnets.com> wrote:
> >>>>> "BL" == Bart Lateur <bart.lateur@skynet.be> writes:
>
> >> So, the Schwartzian Transform is wrong?
>
> BL> No. The Schwartzian Transform does not depend on a particular
> BL> execution order for the elements. It merely converts elements of a
> BL> list (but without even changing the elements themselves) into a
> BL> different representation, sort on that, and then extract the
> BL> original data again.
>
> wrong. the extract map in the ST has to keep the data in the sorted
> order.
Uri, you fail to understand the issue. You're talking about return
order; Bart is discussing *execution* order.
map will, of course, return the list in order from first to last. But
there is no guarantee that it will *process* the list in that order.
For example, map could start with the last element of the list, proceed
to the first element of the list, and then return the results from first
to last.
--
_ / ' _ / - aka - rjk@linguist.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Tue, 23 Feb 1999 20:59:04 -0500
From: rjk@linguist.dartmouth.edu (Ronald J Kimball)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <1dnp4oy.1fk4gnt10ssgN@bay1-193.quincy.ziplink.net>
Abigail <abigail@fnx.com> wrote:
> ?? >Oh, really? Then tell, what can we use map {} for?
> ??
> ?? To build a list of function results, starting from a list of parameters.
> ?? Nothing more, nothing less.
>
> But without knowing the order. And the random order gives us what benefits?
The "random order" could give us the benefit of implementing map in
parellel, so that several elements are processed at the same time. This
would make map more efficient, but it means the execution order cannot
be fixed.
But since backwards-compatibility requires that Perl's map always
execute in first-to-last order, map will never have a parellel
implementation. Too bad.
> ?? >So, the Schwartzian Transform is wrong?
> ??
> ?? No. The Schwartzian Transform does not depend on a particular execution
> ?? order for the elements.
>
> Oh, it most certainly does if you want to make a stable sort.
See my response to Uri. You're confusing execution order and return
order too.
As Bart said, the Schwartzian Transform does not depend on a particular
execution order.
> my @map3_sorted = map3 {$_ -> [0]}
> sort {$a -> [1] <=> $b -> [1] ||
> $a -> [2] <=> $b -> [2]}
> map3 {[$_, /(\d+)/, $i ++]} @unsorted;
This is a pointless example. The elements are *already* sorted with
regards to $a->[2] and $b->[2], so that second comparison is completely
needless.
--
_ / ' _ / - aka - rjk@linguist.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: 24 Feb 1999 04:10:57 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <7avu4h$csc$1@client2.news.psi.net>
Ronald J Kimball (rjk@linguist.dartmouth.edu) wrote on MMIII September
MCMXCIII in <URL:news:1dnp4oy.1fk4gnt10ssgN@bay1-193.quincy.ziplink.net>:
@@ Abigail <abigail@fnx.com> wrote:
@@
@@ > ?? >Oh, really? Then tell, what can we use map {} for?
@@ > ??
@@ > ?? To build a list of function results, starting from a list of parameters.
@@ > ?? Nothing more, nothing less.
@@ >
@@ > But without knowing the order. And the random order gives us what benefits?
@@
@@ The "random order" could give us the benefit of implementing map in
@@ parellel, so that several elements are processed at the same time. This
@@ would make map more efficient, but it means the execution order cannot
@@ be fixed.
Idem for foreach(), while() and even a set of assignments. None of them
can easily be deserialized without possible consequences.
@@ But since backwards-compatibility requires that Perl's map always
@@ execute in first-to-last order, map will never have a parellel
@@ implementation. Too bad.
@@
@@
@@ > ?? >So, the Schwartzian Transform is wrong?
@@ > ??
@@ > ?? No. The Schwartzian Transform does not depend on a particular execution
@@ > ?? order for the elements.
@@ >
@@ > Oh, it most certainly does if you want to make a stable sort.
@@
@@ See my response to Uri. You're confusing execution order and return
@@ order too.
No. See my example.
@@ As Bart said, the Schwartzian Transform does not depend on a particular
@@ execution order.
@@
@@
@@ > my @map3_sorted = map3 {$_ -> [0]}
@@ > sort {$a -> [1] <=> $b -> [1] ||
@@ > $a -> [2] <=> $b -> [2]}
@@ > map3 {[$_, /(\d+)/, $i ++]} @unsorted;
@@
@@ This is a pointless example. The elements are *already* sorted with
@@ regards to $a->[2] and $b->[2], so that second comparison is completely
@@ needless.
But they don't have to stay sorted. If they would, a sorted list would
never differ from an unsorted one, would it?
Abigail
--
%0=map{reverse+chop,$_}ABC,ACB,BAC,BCA,CAB,CBA;$_=shift().AC;1while+s/(\d+)((.)
(.))/($0=$1-1)?"$0$3$0{$2}1$2$0$0{$2}$4":"$3 => $4\n"/xeg;print#Towers of Hanoi
------------------------------
Date: Wed, 24 Feb 1999 00:30:20 -0500
From: rjk@linguist.dartmouth.edu (Ronald J Kimball)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <1dnpfd8.1ip3ujc17si4ubN@bay1-193.quincy.ziplink.net>
Abigail <abigail@fnx.com> wrote:
> @@ As Bart said, the Schwartzian Transform does not depend on a particular
> @@ execution order.
> @@
> @@
> @@ > my @map3_sorted = map3 {$_ -> [0]}
> @@ > sort {$a -> [1] <=> $b -> [1] ||
> @@ > $a -> [2] <=> $b -> [2]}
> @@ > map3 {[$_, /(\d+)/, $i ++]} @unsorted;
> @@
> @@ This is a pointless example. The elements are *already* sorted with
> @@ regards to $a->[2] and $b->[2], so that second comparison is completely
> @@ needless.
>
>
> But they don't have to stay sorted. If they would, a sorted list would
> never differ from an unsorted one, would it?
Ah, I see what I missed... Quiksort may swap elements out of order in
the process of sorting them.
I guess that particular Schwartzian Transform does depend on order of
execution of map.
--
chipmunk (Ronald J Kimball) <rjk@linguist.dartmouth.edu>
perl -e 'print map chop, sort split shift, reverse shift
' 'j_' 'e._jP;_jr/_je=_jk{_jn*_j &_j :_j @_jr}_ja)_js$_j
~_jh]_jt,_jo+_jJ"_jr>_ju#_jt%_jl?_ja^_jc`_jh-_je|' -rjk-
------------------------------
Date: Wed, 24 Feb 1999 12:31:50 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <36d3ed55.11745162@news.skynet.be>
Abigail wrote:
>my $i = 0;
>my @map_sorted = map {$_ -> [0]}
> sort {$a -> [1] <=> $b -> [1] ||
> $a -> [2] <=> $b -> [2]}
> map {[$_, /(\d+)/, $i ++]} @unsorted;
^^^^^^ side effect
... same for map3
>print "@map_sorted\n";
>print "@map3_sorted\n";
>
>__END__
>1k 2e 3j 6c 6i 7h 8b 8f 9g 10a 10d
>1k 2e 3j 6i 6c 7h 8f 8b 9g 10d 10a
>
>They are sorted differently. I'd call map3 broken.
No, it's your code that is broken. Your using a side effect.What are you
trying to do, keep the original order if the items are equivalent? That
is silly. If all fails, simply sorting alphabetically makes more sense,
I would think.
sub map3 (&@) {
my $func = shift;
my @result;
foreach (reverse @_) {
unshift @result, $func->();
}
return wantarray?@result:$result[-1];
}
sub shuffle {
my @shuffled;
while(@_) {
push @shuffled, splice @_, int(rand @_),1;
}
@shuffled;
}
for(my $j =0; $j<3; $j++) {
@unsorted = shuffled(qw (10a 8b 6c 10d 2e 8f 9g 7h 6i 3j 1k));
my $i = 0;
my @abigail = map {$_ -> [0]}
sort {$a -> [1] <=> $b -> [1] ||
$a -> [2] <=> $b -> [2]}
map {[$_, /(\d+)/, $i ++]} @unsorted;
my @bart = map3 {$_ -> [0]}
sort {$a -> [1] <=> $b -> [1] ||
$a -> [0] cmp $b -> [0]}
map {[$_, /(\d+)/]} @unsorted;
print "Abigail: @abigail\n";
print "Bart: @bart\n";
}
__END__
Unsorted: 10d 2e 1k 6i 8f 8b 10a 3j 7h 6c 9g
Abigail: 1k 2e 3j 6i 6c 7h 8f 8b 9g 10d 10a
Bart: 1k 2e 3j 6c 6i 7h 8b 8f 9g 10a 10d
Unsorted: 6c 10d 8f 9g 8b 2e 10a 1k 6i 7h 3j
Abigail: 1k 2e 3j 6c 6i 7h 8f 8b 9g 10d 10a
Bart: 1k 2e 3j 6c 6i 7h 8b 8f 9g 10a 10d
Unsorted: 8b 1k 3j 2e 10d 6i 6c 7h 10a 8f 9g
Abigail: 1k 2e 3j 6i 6c 7h 8b 8f 9g 10d 10a
Bart: 1k 2e 3j 6c 6i 7h 8b 8f 9g 10a 10d
Mine gives the same result every time. Yours doesn't.
Bart.
------------------------------
Date: Wed, 24 Feb 1999 16:23:47 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <36d42109.1925011@news.skynet.be>
Abigail wrote:
>What specs are you talking about? I hope not 'man perlfunc'. I don't
>think that makes a claim to be the specification of Perl. At best,
>it will *describe* what Perl does. Not specify.
If the official language reference doesn't qualify as "the specs", than
something is wrong. The source code for Perl is irrelevant. You've got
to keep your levels separated. Source code may contain bugs, specs must
not.
And you *may never* rely on something that is not explicitely
documented. You could be the only one in the world counting on it.
Bart.
------------------------------
Date: 24 Feb 1999 17:08:45 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <7b1bmt$jie$1@client2.news.psi.net>
Bart Lateur (bart.lateur@skynet.be) wrote on MMIII September MCMXCIII in
<URL:news:36d3ed55.11745162@news.skynet.be>:
.. Abigail wrote:
..
.. >my $i = 0;
.. >my @map_sorted = map {$_ -> [0]}
.. > sort {$a -> [1] <=> $b -> [1] ||
.. > $a -> [2] <=> $b -> [2]}
.. > map {[$_, /(\d+)/, $i ++]} @unsorted;
.. ^^^^^^ side effect
..
.. ... same for map3
..
.. >print "@map_sorted\n";
.. >print "@map3_sorted\n";
.. >
.. >__END__
.. >1k 2e 3j 6c 6i 7h 8b 8f 9g 10a 10d
.. >1k 2e 3j 6i 6c 7h 8f 8b 9g 10d 10a
.. >
.. >They are sorted differently. I'd call map3 broken.
..
.. No, it's your code that is broken. Your using a side effect.
Uhm, give me an example of a useful Perl statement that doesn't use
a side effect. I very much doubt you can find one.
.. What are you
.. trying to do, keep the original order if the items are equivalent?
Yes.
.. That
.. is silly.
Really? Please read the literature. There is a need for stable sorts.
.. If all fails, simply sorting alphabetically makes more sense,
.. I would think.
You're wrong. It has nothing to do with alphabetically sorting. *STABLE*
sorting is what I want; don't get confused just because I used letters
from a familiar alphabet.
.. sub map3 (&@) {
.. my $func = shift;
My, my, my, a side effect.
.. my @result;
Another side effect!
.. foreach (reverse @_) {
Look ma, another side effect!
.. unshift @result, $func->();
And another.... Maybe it's time to change your mind about side effects?
.. }
.. return wantarray?@result:$result[-1];
.. }
.. sub shuffle {
.. my @shuffled;
.. while(@_) {
.. push @shuffled, splice @_, int(rand @_),1;
.. }
.. @shuffled;
.. }
..
.. for(my $j =0; $j<3; $j++) {
.. @unsorted = shuffled(qw (10a 8b 6c 10d 2e 8f 9g 7h 6i 3j 1k));
.. my $i = 0;
.. my @abigail = map {$_ -> [0]}
.. sort {$a -> [1] <=> $b -> [1] ||
.. $a -> [2] <=> $b -> [2]}
.. map {[$_, /(\d+)/, $i ++]} @unsorted;
..
.. my @bart = map3 {$_ -> [0]}
.. sort {$a -> [1] <=> $b -> [1] ||
.. $a -> [0] cmp $b -> [0]}
.. map {[$_, /(\d+)/]} @unsorted;
..
.. print "Abigail: @abigail\n";
.. print "Bart: @bart\n";
.. }
.. __END__
.. Unsorted: 10d 2e 1k 6i 8f 8b 10a 3j 7h 6c 9g
.. Abigail: 1k 2e 3j 6i 6c 7h 8f 8b 9g 10d 10a
.. Bart: 1k 2e 3j 6c 6i 7h 8b 8f 9g 10a 10d
^^^^^ ^^^^ ^^^^^^^ 3 mistakes.
.. Unsorted: 6c 10d 8f 9g 8b 2e 10a 1k 6i 7h 3j
.. Abigail: 1k 2e 3j 6c 6i 7h 8f 8b 9g 10d 10a
.. Bart: 1k 2e 3j 6c 6i 7h 8b 8f 9g 10a 10d
^^^^^ ^^^^^^^ 2 mistakes.
.. Unsorted: 8b 1k 3j 2e 10d 6i 6c 7h 10a 8f 9g
.. Abigail: 1k 2e 3j 6i 6c 7h 8b 8f 9g 10d 10a
.. Bart: 1k 2e 3j 6c 6i 7h 8b 8f 9g 10a 10d
^^^^^ ^^^^^^^ 2 mistakes.
..
..
.. Mine gives the same result every time. Yours doesn't.
Yours give the wrong result. I'd prefer a correct algorithm.
Abigail
--
sub _'_{$_'_=~s/$a/$_/}map{$$_=$Z++}Y,a..z,A..X;*{($_::_=sprintf+q=%X==>"$A$Y".
"$b$r$T$u")=~s~0~O~g;map+_::_,U=>T=>L=>$Z;$_::_}=*_;sub _{print+/.*::(.*)/s}
*_'_=*{chr($b*$e)};*__=*{chr(1<<$e)};
_::_(r(e(k(c(a(H(__(l(r(e(P(__(r(e(h(t(o(n(a(__(t(us(J())))))))))))))))))))))))
------------------------------
Date: 24 Feb 1999 23:40:42 GMT
From: abigail@fnx.com (Abigail)
Subject: Re: change column of nmbers to 2 dim array
Message-Id: <7b22lq$nd1$2@client2.news.psi.net>
Bart Lateur (bart.lateur@skynet.be) wrote on MMIII September MCMXCIII in
<URL:news:36d42109.1925011@news.skynet.be>:
** Abigail wrote:
**
** >What specs are you talking about? I hope not 'man perlfunc'. I don't
** >think that makes a claim to be the specification of Perl. At best,
** >it will *describe* what Perl does. Not specify.
**
** If the official language reference doesn't qualify as "the specs", than
** something is wrong. The source code for Perl is irrelevant. You've got
** to keep your levels separated. Source code may contain bugs, specs must
** not.
I'm not saying source code is bug free. I'm not saying specs should be
allowed to have dates. But that doesn't make the man page a specification.
It isn't. It *can't* be. It was written after perl, and it describes Perl,
not specify it.
** And you *may never* rely on something that is not explicitely
** documented. You could be the only one in the world counting on it.
I presume you take care of the sitution where perl turns your desk
into yello? After all, it isn't documented it won't do so.
Abigail
--
sub _'_{$_'_=~s/$a/$_/}map{$$_=$Z++}Y,a..z,A..X;*{($_::_=sprintf+q=%X==>"$A$Y".
"$b$r$T$u")=~s~0~O~g;map+_::_,U=>T=>L=>$Z;$_::_}=*_;sub _{print+/.*::(.*)/s}
*_'_=*{chr($b*$e)};*__=*{chr(1<<$e)};
_::_(r(e(k(c(a(H(__(l(r(e(P(__(r(e(h(t(o(n(a(__(t(us(J())))))))))))))))))))))))
------------------------------
Date: 12 Dec 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 4962
**************************************
