[32360] in Perl-Users-Digest
Perl-Users Digest, Issue: 3627 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Mar 1 11:09:24 2012
Date: Thu, 1 Mar 2012 08:09:06 -0800 (PST)
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, 1 Mar 2012 Volume: 11 Number: 3627
Today's topics:
Re: access to variable names inside subprocedure <ben@morrow.me.uk>
Re: access to variable names inside subprocedure <mvdwege@mail.com>
Re: access to variable names inside subprocedure <bugbear@trim_papermule.co.uk_trim>
Re: given...when (Seymour J.)
Re: lang comparison: in-place algorithm for reversing a <rweikusat@mssgmbh.com>
lang comparison: in-place algorithm for reversing a lis <xahlee@gmail.com>
Re: lang comparison: in-place algorithm for reversing a <w_a_x_man@yahoo.com>
Re: New Science Discovery: Perl Detracters Remain Idiot (Seymour J.)
Re: New Science Discovery: Perl Detracters Remain Idiot <chiron613@gmail.com>
Re: New Science Discovery: Perl Idiots Remain Idiots Af (Seymour J.)
Re: New Science Discovery: Perl Idiots Remain Idiots Af <rweikusat@mssgmbh.com>
Re: New Science Discovery: Perl Idiots Remain Idiots Af <kiuhnm03.4t.yahoo.it>
Re: New Science Discovery: Perl Idiots Remain Idiots Af <xahlee@gmail.com>
Re: New Science Discovery: Perl Idiots Remain Idiots Af <chiron613@gmail.com>
Re: sample scripts for solving euler problems <example.scripts@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 29 Feb 2012 23:23:29 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: access to variable names inside subprocedure
Message-Id: <hko229-sp4.ln1@anubis.morrow.me.uk>
Quoth ccc31807 <cartercc@gmail.com>:
> On Feb 29, 4:45 pm, Ben Morrow <b...@morrow.me.uk> wrote:
> > Come on, you've been here long enough to know that.
>
> Maybe, but we all tend to become more narrow in the course of time. I
> consider myself moderately competent in what I do, which is a
> combination of web applications, database applications, and data
> munging, but I've never run across PadWalker.
Well, no. It's a neat trick, and it's useful for debugging, but it's not
reliable enough for production use.
> I'm not actually a programmer, much less a Perl expert. I use Perl to
> perform my job functions, and don't spend much time writing code.
>
> > If you insist: PadWalker.
>
> Thanks for the tip. I have glanced through it, and see how it could be
> useful. I'm going to play with it some.
That was not a helpful tip. It was a sarcastic nudge in the wrong
direction, since you seem determined to go that way.
The right answer, as the FAQ entry I pointed you to says, is: don't try
to use a string as a variable name (or a variable name as a string).
Instead of keeping your data in separate variables, put it all in a
hash, which is naturally keyed by strings.
In this case, given the sort of program you're probably writing, I'd
probably use a single global rather than trying to pass it around. So,
something along the lines of:
my %Data;
for (qw/fileone filetwo/) {
read_file $_;
write_file $_;
}
sub read_file {
my ($file) = @_;
open my $F, "<", $file or die ...;
$Data{$file} = [ <$F> ];
}
sub write_file {
my ($file) = @_;
open my $F, ">", $file or die ...;
for (@{ $Data{$file} }) {
print $F $_;
}
}
Ben
------------------------------
Date: Thu, 01 Mar 2012 08:48:19 +0100
From: Mart van de Wege <mvdwege@mail.com>
Subject: Re: access to variable names inside subprocedure
Message-Id: <86k4347oe4.fsf@gaheris.avalon.lan>
ccc31807 <cartercc@gmail.com> writes:
> On Feb 29, 12:44Â pm, "J. Gleixner" <glex_no-s...@qwest-spam-
> no.invalid> wrote:
>> 'hashref1' is not a terribly helpful filename.
>>
>> If 'hashref1' is in the data, then pass $hashref1 and pull the filename
>> from the data.
>
> You are right ... I'm actually using long English names for the
> hashes, like $daily_site_count_by_type, and $daily_counts_by_status. I
> can generate these filenames from the data as I pass through it. Other
> than that, I don't care what the names are.
>
If you're constructing your names on the fly, why don't you then just
put your data in a hash, using the names as a key?
The description of your problem should cry out 'hash!' to any competent
programmer.
Mart
--
"We will need a longer wall when the revolution comes."
--- AJS, quoting an uncertain source.
------------------------------
Date: Thu, 01 Mar 2012 09:01:44 +0000
From: bugbear <bugbear@trim_papermule.co.uk_trim>
Subject: Re: access to variable names inside subprocedure
Message-Id: <ZridnclDVY5lp9LSnZ2dnUVZ7tSdnZ2d@brightview.co.uk>
Mart van de Wege wrote:
> ccc31807<cartercc@gmail.com> writes:
>
>> On Feb 29, 12:44 pm, "J. Gleixner"<glex_no-s...@qwest-spam-
>> no.invalid> wrote:
>>> 'hashref1' is not a terribly helpful filename.
>>>
>>> If 'hashref1' is in the data, then pass $hashref1 and pull the filename
>>> from the data.
>>
>> You are right ... I'm actually using long English names for the
>> hashes, like $daily_site_count_by_type, and $daily_counts_by_status. I
>> can generate these filenames from the data as I pass through it. Other
>> than that, I don't care what the names are.
>>
> If you're constructing your names on the fly, why don't you then just
> put your data in a hash, using the names as a key?
>
> The description of your problem should cry out 'hash!' to any competent
> programmer.
Or (more generally) when in doubt, add indirection.
BugBear
------------------------------
Date: Tue, 28 Feb 2012 19:47:37 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: given...when
Message-Id: <4f4d75a9$22$fuzhry+tra$mr2ice@news.patriot.net>
In <4f4d5303$0$1384$4fafbaef@reader2.news.tin.it>, on 02/28/2012
at 11:19 PM, Kiuhnm <kiuhnm03.4t.yahoo.it> said:
>I understand, but why not using a smarter tool?
It's not enough that *I* use a smarter tool; I'd also have to convince
everybody using my code to use a smarter tool as well. Good, bad or
indifferent, diff is what most people have.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 01 Mar 2012 14:39:25 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: lang comparison: in-place algorithm for reversing a list in Perl, Python, Lisp
Message-Id: <87obsg1j36.fsf@sapphire.mobileactivedefense.com>
Xah Lee <xahlee@gmail.com> writes:
[...]
> # perl
> # in-place algorithm for reversing a list.
>
> use strict;
> use Data::Dumper;
> use POSIX; # for “floor”
>
> my @listA = qw(a b c d e f g);
>
> my $listLength = scalar @listA;
>
> for ( my $i = 0; $i < floor($listLength/2); $i++ ) {
> my $x = $listA[$i];
> $listA[$i] = $listA[ $listLength - 1 - $i];
> $listA[ $listLength - 1 - $i] = $x;
> }
>
> print Dumper(\@listA);
Better algorithm for that (expects an array reference as first
argument)
sub rev
{
my $a = $_[0];
my ($n0, $n1, $x);
$n0 = 0;
$n1 = $#$a;
while ($n0 < $n1) {
$x = $a->[$n0];
$a->[$n0] = $a->[$n1];
$a->[$n1] = $x;
++$n0;
--$n1;
}
}
NB: The fact that a sufficiently sophisticated compiler might be able
to fix this automatically emphasizes the deficiencies of the original
attempt, it doesn't excuse them.
------------------------------
Date: Wed, 29 Feb 2012 20:07:49 -0800 (PST)
From: Xah Lee <xahlee@gmail.com>
Subject: lang comparison: in-place algorithm for reversing a list in Perl, Python, Lisp
Message-Id: <85fa5760-68c8-41a2-9116-2489165f7ca1@j5g2000yqm.googlegroups.com>
fun example.
in-place algorithm for reversing a list in Perl, Python, Lisp
http://xahlee.org/comp/in-place_algorithm.html
plain text follows
----------------------------------------
What's =93In-place Algorithm=94?
Xah Lee, 2012-02-29
This page tells you what's =93In-place algorithm=94, using {python, perl,
emacs lisp} code to illustrate.
Here's Wikipedia In-place algorithm excerpt:
In computer science, an in-place algorithm (or in Latin in situ) is an
algorithm which transforms input using a data structure with a small,
constant amount of extra storage space. The input is usually
overwritten by the output as the algorithm executes. An algorithm
which is not in-place is sometimes called not-in-place or out-of-
place.
Python
Here's a python code for reversing a list. Done by creating a new
list, NOT using in-place:
# python
# reverse a list
list_a =3D ["a", "b", "c", "d", "e", "f", "g"]
list_length =3D len(list_a)
list_b =3D [0] * list_length
for i in range(list_length):
list_b[i] =3D list_a[list_length -1 - i]
print list_b
Here's in-place algorithm for reversing a list:
# python
# in-place algorithm for reversing a list
list_a =3D ["a", "b", "c", "d", "e", "f", "g"]
list_length =3D len(list_a)
for i in range(list_length/2):
x =3D list_a[i]
list_a[i] =3D list_a[ list_length -1 - i]
list_a[ list_length -1 - i] =3D x
print list_a
Perl
Here's a perl code for reversing a list. Done by creating a new list,
NOT using in-place:
# perl
use strict;
use Data::Dumper;
my @listA =3D qw(a b c d e f g);
my $listLength =3D scalar @listA;
my @listB =3D ();
for ( my $i =3D 0; $i < $listLength; $i++ ) {
$listB[$i] =3D $listA[ $listLength - 1 - $i];
}
print Dumper(\@listB);
# perl
# in-place algorithm for reversing a list.
use strict;
use Data::Dumper;
use POSIX; # for =93floor=94
my @listA =3D qw(a b c d e f g);
my $listLength =3D scalar @listA;
for ( my $i =3D 0; $i < floor($listLength/2); $i++ ) {
my $x =3D $listA[$i];
$listA[$i] =3D $listA[ $listLength - 1 - $i];
$listA[ $listLength - 1 - $i] =3D $x;
}
print Dumper(\@listA);
__END__
emacs lisp
;; emacs lisp
;; reverse a array
(setq arrayA ["a" "b" "c" "d" "e" "f" "g"])
(setq arrayLength (length arrayA))
(setq arrayB (make-vector arrayLength 0))
(dotimes (i arrayLength )
(aset arrayB i (aref arrayA (- (1- arrayLength) i)) )
)
(print (format "%S" arrayB))
;; emacs lisp
;; in-place algorithm for reversing a array
(setq arrayA ["a" "b" "c" "d" "e" "f" "g"])
(setq arrayLength (length arrayA))
(dotimes (i (floor (/ arrayLength 2)))
(let (x)
(setq x (aref arrayA i))
(aset arrayA i (aref arrayA (- (1- arrayLength) i)))
(aset arrayA (- (1- arrayLength) i) x) ) )
(print (format "%S" arrayA))
Xah
------------------------------
Date: 1 Mar 2012 06:37:45 GMT
From: "WJ" <w_a_x_man@yahoo.com>
Subject: Re: lang comparison: in-place algorithm for reversing a list in Perl,Python, Lisp
Message-Id: <jin5fp03os@enews1.newsguy.com>
Xah Lee wrote:
> fun example.
>
> in-place algorithm for reversing a list in Perl, Python, Lisp
> http://xahlee.org/comp/in-place_algorithm.html
>
> plain text follows
> ----------------------------------------
>
> What's “In-place Algorithm”?
>
> Xah Lee, 2012-02-29
>
> This page tells you what's “In-place algorithm”, using {python, perl,
> emacs lisp} code to illustrate.
>
> Here's Wikipedia In-place algorithm excerpt:
>
> In computer science, an in-place algorithm (or in Latin in situ) is an
> algorithm which transforms input using a data structure with a small,
> constant amount of extra storage space. The input is usually
> overwritten by the output as the algorithm executes. An algorithm
> which is not in-place is sometimes called not-in-place or out-of-
> place.
>
> Python
>
> Here's a python code for reversing a list. Done by creating a new
> list, NOT using in-place:
>
> # python
> # reverse a list
>
> list_a = ["a", "b", "c", "d", "e", "f", "g"]
>
> list_length = len(list_a)
> list_b = [0] * list_length
>
> for i in range(list_length):
> list_b[i] = list_a[list_length -1 - i]
>
> print list_b
> Here's in-place algorithm for reversing a list:
>
> # python
> # in-place algorithm for reversing a list
>
> list_a = ["a", "b", "c", "d", "e", "f", "g"]
>
> list_length = len(list_a)
>
> for i in range(list_length/2):
> x = list_a[i]
> list_a[i] = list_a[ list_length -1 - i]
> list_a[ list_length -1 - i] = x
>
> print list_a
> Perl
>
> Here's a perl code for reversing a list. Done by creating a new list,
> NOT using in-place:
>
> # perl
>
> use strict;
> use Data::Dumper;
>
> my @listA = qw(a b c d e f g);
>
> my $listLength = scalar @listA;
> my @listB = ();
>
> for ( my $i = 0; $i < $listLength; $i++ ) {
> $listB[$i] = $listA[ $listLength - 1 - $i];
> }
>
> print Dumper(\@listB);
>
> # perl
> # in-place algorithm for reversing a list.
>
> use strict;
> use Data::Dumper;
> use POSIX; # for “floor”
>
> my @listA = qw(a b c d e f g);
>
> my $listLength = scalar @listA;
>
> for ( my $i = 0; $i < floor($listLength/2); $i++ ) {
> my $x = $listA[$i];
> $listA[$i] = $listA[ $listLength - 1 - $i];
> $listA[ $listLength - 1 - $i] = $x;
> }
>
> print Dumper(\@listA);
> __END__
>
> emacs lisp
>
> ;; emacs lisp
> ;; reverse a array
>
> (setq arrayA ["a" "b" "c" "d" "e" "f" "g"])
>
> (setq arrayLength (length arrayA))
>
> (setq arrayB (make-vector arrayLength 0))
>
> (dotimes (i arrayLength )
> (aset arrayB i (aref arrayA (- (1- arrayLength) i)) )
> )
>
> (print (format "%S" arrayB))
> ;; emacs lisp
> ;; in-place algorithm for reversing a array
>
> (setq arrayA ["a" "b" "c" "d" "e" "f" "g"])
>
> (setq arrayLength (length arrayA))
>
> (dotimes (i (floor (/ arrayLength 2)))
> (let (x)
> (setq x (aref arrayA i))
> (aset arrayA i (aref arrayA (- (1- arrayLength) i)))
> (aset arrayA (- (1- arrayLength) i) x) ) )
>
> (print (format "%S" arrayA))
>
MatzLisp:
a = [2,3,5,8]
==>[2, 3, 5, 8]
a.reverse!
==>[8, 5, 3, 2]
a
==>[8, 5, 3, 2]
------------------------------
Date: Wed, 29 Feb 2012 23:06:42 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: New Science Discovery: Perl Detracters Remain Idiots After A Decade!
Message-Id: <4f4ef5d2$26$fuzhry+tra$mr2ice@news.patriot.net>
In <ubo3r.20367$kv1.9848@newsfe03.iad>, on 02/29/2012
at 11:43 AM, Chiron <chiron613@gmail.com> said:
>Sure, mathematically it *should* go a particular way,
No. Mathematically it should go the way that it is defined to go.
There is nothing in Mathematics that either requires or prohibits
infix notation in programming languages, or even in Mathematical
notation.
>it makes sense to keep things as clear as possible.
Often infix notation with well thought out precedence is the clearest
way to go. RPN and the like have their place, but often are difficult
for real people to read.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 01 Mar 2012 04:52:27 GMT
From: Chiron <chiron613@gmail.com>
Subject: Re: New Science Discovery: Perl Detracters Remain Idiots After A Decade!
Message-Id: <fgD3r.7862$_63.3414@newsfe19.iad>
On Wed, 29 Feb 2012 23:06:42 -0500, Shmuel (Seymour J.) Metz wrote:
> In <ubo3r.20367$kv1.9848@newsfe03.iad>, on 02/29/2012
> at 11:43 AM, Chiron <chiron613@gmail.com> said:
>
>>Sure, mathematically it *should* go a particular way,
>
> No. Mathematically it should go the way that it is defined to go. There
> is nothing in Mathematics that either requires or prohibits infix
> notation in programming languages, or even in Mathematical notation.
>
Yes. That (the mathematically defined way) is a particular way, is it
not?
>>it makes sense to keep things as clear as possible.
>
> Often infix notation with well thought out precedence is the clearest
> way to go. RPN and the like have their place, but often are difficult
> for real people to read.
However, I wasn't specifically referring to infix/postfix/prefix or
anything of that nature. I wasn't limiting my comment to lisp notation
in particular, since what I said applies to any language. I was
referring to the placement of parentheses (or other groupings) to
indicate to *humans* what the intended sequence of events was. The
problem with precedence is that it is not always clear how it will go.
Different languages have different rules, some of which depart from the
rules in mathematics. Some implementations of languages are buggy in
this regard.
Mathematically, and in any language with which I am familiar, the
sequence: 2 + 6 / 3 will yield 4. It is unnecessary, but harmless, to
write this as 2 + (6 / 3). A naive reader (or just a tired or hurried
one) might come up with 8 / 3 if there aren't any parentheses.
Whenever there is *any* possibility of ambiguity, I see no reason not to
clarify. Back in the days when the way you wrote your code affected how
it was compiled, it made sense to rely heavily on language-specific
features, thus saving a few bytes. With gigabyte memories, gigahertz
clock speeds, and optimizing compilers, the pressure to try to optimize
by hand is gone. A few extra parentheses, or even breaking down a
complex sequence of events into discrete, simpler ones, is no longer a
costly luxury. A few extra variables, if they help clarity, aren't going
to hurt anything. Let the machine do the grunt work. Pamper your
readers (which in a few weeks or months might be you) and show exactly
what you had in mind. That's all I'm saying.
--
I'd just as soon kiss a Wookie.
-- Princess Leia Organa
------------------------------
Date: Wed, 29 Feb 2012 23:10:48 -0500
From: Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>
Subject: Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots Af
Message-Id: <4f4ef6c8$27$fuzhry+tra$mr2ice@news.patriot.net>
In <87aa41k6x5.fsf@sapphire.mobileactivedefense.com>, on 02/29/2012
at 03:15 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>'mathematics' (an essentially outdated write-only programming
>language dating back to the times when humans had to perform
>computations themselves)
ROTF,LMAO! You obviously don't have a clue as to what Mathematics
means. Free hint: it doesn't mean Arithmetic. You're as bigoted as Xah
Lee,
--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>
Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org
------------------------------
Date: Thu, 01 Mar 2012 14:40:58 +0000
From: Rainer Weikusat <rweikusat@mssgmbh.com>
Subject: Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots Af
Message-Id: <87k4341j0l.fsf@sapphire.mobileactivedefense.com>
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
> In <87aa41k6x5.fsf@sapphire.mobileactivedefense.com>, on 02/29/2012
> at 03:15 PM, Rainer Weikusat <rweikusat@mssgmbh.com> said:
>
>>'mathematics' (an essentially outdated write-only programming
>>language dating back to the times when humans had to perform
>>computations themselves)
>
> ROTF,LMAO! You obviously don't have a clue as to what Mathematics
> means. Free hint: it doesn't mean Arithmetic.
You obviously don't have any sense of humour. But don't let this
trouble you.
------------------------------
Date: Thu, 01 Mar 2012 12:00:26 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots After A Decade!
Message-Id: <4f4f56c8$0$1381$4fafbaef@reader2.news.tin.it>
On 3/1/2012 1:02, Xah Lee wrote:
> i missed a point in my original post. That is, when the same operator
> are adjacent. e.g. 「3 ▲ 6 ▲ 5」.
>
> This is pointed out by Kiuhnm 〔kiuhnm03.4t.yahoo.it〕 and Tim Bradshaw.
> Thanks.
>
> though, i disagree the way they expressed it, or any sense this is
> different from math.
They did not make up the terminology, if that is what you are saying.
The concepts of left and right associativity are well-known and accepted
in TCS (Theoretical CS).
If you change the terminology, no one will understand you unless you
provide your definitions every time (and then they may not accept them).
Another way of saying that an operator is left-associative is that its
parse tree is a left-tree, i.e. a complete tree where each right child
is a leaf.
For instance, (use a monospaced font)
1 + 2 + 3 + 4
gives you this left-tree:
+
+ 4
+ 3
1 2
while 1**2**3**4
gives you this right-tree:
**
1 **
2 **
3 4
Aho, Sethi and Ullman explain it this way in "Compilers: Principles,
Techniques and Tools":
"We say that the operator + associates to the left because an operand
with plus signs on both sides of it is taken by the operator to its
left. [...]"
And they also show parse trees similar to the ones I wrote above.
Kiuhnm
------------------------------
Date: Wed, 29 Feb 2012 16:02:39 -0800 (PST)
From: Xah Lee <xahlee@gmail.com>
Subject: Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots After A Decade!
Message-Id: <9dc55d52-3902-4449-87e7-745fb8b911b3@n12g2000yqb.googlegroups.com>
i missed a point in my original post. That is, when the same operator
are adjacent. e.g. =E3=80=8C3 =E2=96=B2 6 =E2=96=B2 5=E3=80=8D.
This is pointed out by Kiuhnm =E3=80=94kiuhnm03.4t.yahoo.it=E3=80=95 and Ti=
m Bradshaw.
Thanks.
though, i disagree the way they expressed it, or any sense this is
different from math.
to clarify, amend my original post, here's what's needed for binary
operator precedence:
=E2=91=A0 the symbols are ordered. (e.g. given a unique integer)
=E2=91=A1 each symbol is has either one of left-side stickness or right-sid=
e
stickness spec. (needed when adjacent symbols are the same.)
About the lisp case mentioned by Tim, e.g. in=E3=80=8C(f a b c)=E3=80=8D, =
whether it
means =E3=80=8C(f (f a b) c)=E3=80=8D or =E3=80=8C(f a (f b c))=E3=80=8D . =
It is not directly relevant
to the context of my original post, because it isn't about to
operators. It's about function argument eval order. Good point,
nevertheless.
the perl doc, is still misleading, terribly bad written. Becha ass!
Xah
On Feb 29, 4:08=C2=A0am, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> On 2/29/2012 9:09, Xah Lee wrote:
>
>
> > New Science Discovery: Perl Idiots Remain Idiots After A Decade!
>
> > A excerpt from the new book =E3=80=88Modern Perl=E3=80=89, just publish=
ed, chapter 4
> > on =E2=80=9COperators=E2=80=9D. Quote:
>
> > =C2=ABThe associativity of an operator governs whether it evaluates fro=
m
> > left to right or right to left. Addition is left associative, such
> > that 2 + 3 + 4 evaluates 2 + 3 first, then adds 4 to the result.
> > Exponentiation is right associative, such that 2 ** 3 ** 4 evaluates 3
> > ** 4 first, then raises 2 to the 81st power. =C2=BB
>
> > LOL. Looks like the perl folks haven't changed. Fundamentals of
> > serious math got botched so badly.
>
> > Let me explain the idiocy.
>
> > It says =E2=80=9CThe associativity of an operator governs whether it ev=
aluates
> > from left to right or right to left.=E2=80=9D. Ok, so let's say we have=
2
> > operators: a white triangle =E2=96=B3 and a black triangle =E2=96=B2. N=
ow, by the
> > perl's teaching above, let's suppose the white triangle is =E2=80=9Crig=
ht
> > associative=E2=80=9D and the black triangle is =E2=80=9Cleft associativ=
e=E2=80=9D. Now, look
> > at this:
>
> > 3 =E2=96=B3 6 =E2=96=B2 5
>
> > seems like the white and black triangles are going to draw a pistol
> > and fight for the chick 6 there. LOL.
>
> Sorry, but you're wrong and they're right.
> Associativity governs the order of evaluation of a group of operators
> *OF THE SAME PRECEDENCE*.
> If you write
> =C2=A0 =C2=A02**3**4
> only the fact the '**' is right associative will tell you that the order =
is
> =C2=A0 =C2=A02**(3**4)
> and not
> =C2=A0 =C2=A0(2**3)**4
> I remind you that 2^(3^4) !=3D (2^3)^4.
>
> Kiuhnm
------------------------------
Date: Thu, 01 Mar 2012 05:07:47 GMT
From: Chiron <chiron613@gmail.com>
Subject: Re: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots Af
Message-Id: <DuD3r.21706$cL.12835@newsfe17.iad>
On Wed, 29 Feb 2012 23:10:48 -0500, Shmuel (Seymour J.) Metz wrote:
> ROTF,LMAO! You obviously don't have a clue as to what Mathematics means.
> Free hint: it doesn't mean Arithmetic. You're as bigoted as Xah Lee,
Hmm... maybe, instead of just ridiculing him, you could explain where he
is mistaken. Of course, doing that is a *LOT* harder than just calling
him a bigot.
BTW, I happen to agree with you insofar as this poster not understanding
the nature of mathematics. His comment reminds me of the article,
"Transgressing the Boundaries: Towards a Transformative Hermeneutics of
Quantum Gravity" (http://www.physics.nyu.edu/sokal/transgress_v2/
transgress_v2_singlefile.html). Also known as the "Sokal Hoax."
--
Boling's postulate:
If you're feeling good, don't worry. You'll get over it.
------------------------------
Date: Wed, 29 Feb 2012 18:19:14 -0800 (PST)
From: scripts examples <example.scripts@gmail.com>
Subject: Re: sample scripts for solving euler problems
Message-Id: <3a3441d5-4791-40bd-8bc7-3ae24c2e1e53@f2g2000yqh.googlegroups.com>
On Feb 28, 8:00=A0pm, scripts examples <example.scri...@gmail.com>
wrote:
> =A0 =A0Got a web site setup for solving euler problems in python, perl,
> ruby and javascript.
>
> =A0 =A0Feel free to give me any feedback, thanks.
Sorry, forgot the link. Here it is: examplescripts.weebly.com
------------------------------
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 3627
***************************************
