[32359] in Perl-Users-Digest
Perl-Users Digest, Issue: 3626 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Feb 29 18:09:26 2012
Date: Wed, 29 Feb 2012 15:09:09 -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 Wed, 29 Feb 2012 Volume: 11 Number: 3626
Today's topics:
Re: a question about efficiency <justin.1201@purestblue.com>
Re: a question about efficiency <kiuhnm03.4t.yahoo.it>
access to variable names inside subprocedure <cartercc@gmail.com>
Re: access to variable names inside subprocedure <kiuhnm03.4t.yahoo.it>
Re: access to variable names inside subprocedure <glex_no-spam@qwest-spam-no.invalid>
Re: access to variable names inside subprocedure <cartercc@gmail.com>
Re: access to variable names inside subprocedure <cartercc@gmail.com>
Re: access to variable names inside subprocedure <ben@morrow.me.uk>
Re: access to variable names inside subprocedure <cartercc@gmail.com>
Re: New Science Discovery: Perl Idiots Remain Idiots Af <rweikusat@mssgmbh.com>
New Science Discovery: Perl Idiots Remain Idiots After <xahlee@gmail.com>
Re: New Science Discovery: Perl Idiots Remain Idiots Af <kiuhnm03.4t.yahoo.it>
Re: New Science Discovery: Perl Idiots Remain Idiots Af <kiuhnm03.4t.yahoo.it>
Re: New Science Discovery: Perl Idiots Remain Idiots Af <chiron613@gmail.com>
Re: New Science Discovery: Perl Idiots Remain Idiots Af <chiron613@gmail.com>
Re: New Science Discovery: Perl Idiots Remain Idiots Af <namekuseijin@gmail.com>
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 12:15:44 +0000
From: Justin C <justin.1201@purestblue.com>
Subject: Re: a question about efficiency
Message-Id: <ggh129-ide.ln1@zem.masonsmusic.co.uk>
On 2012-02-28, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
>
> Let's put it this way: "Learning Perl" is too gentle and forgiving.
I don't think that is the case if you have no programming background at
all.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 29 Feb 2012 16:30:10 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: a question about efficiency
Message-Id: <4f4e4481$0$1387$4fafbaef@reader1.news.tin.it>
On 2/29/2012 13:15, Justin C wrote:
> On 2012-02-28, Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>>
>> Let's put it this way: "Learning Perl" is too gentle and forgiving.
>
> I don't think that is the case if you have no programming background at
> all.
>
> Justin.
I would have rather gone for "Programming Perl", but it's quite
outdated. Too bad the 4th edition is still unavailable.
Kiuhnm
------------------------------
Date: Wed, 29 Feb 2012 08:35:16 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: access to variable names inside subprocedure
Message-Id: <1ffaafac-3d6b-4d2c-b705-f4cdd818881e@j5g2000yqm.googlegroups.com>
Question: I would like to access the string value of the variable
names passed as arguments to a sub inside the sub.
The following stores a hash in a file named like
'HASH(0xdeadbeef).dat' but I would like to store the hash in a file
named like 'hashref1.dat'.
use Storable;
my $hashref1 = retrieve('hashref1.dat');
my $hashref2 = retrieve('hashref2.dat');
my $hashref3 = retrieve('hashref3.dat');
# extensive processing on $hashref1, $hashref2, and $hashref3
# ... then
save_hashes($hashref1, $hashref2, $hashref3);
exit(0);
sub save_hashes
{
foreach my $hashref (@_)
{
my $filename = sprintf("%s.dat", $hashref);
store($hashref, $filename);
}
}
I can do it by passing the arguments twice, once as a string and the
second time as a variable, like this:
save_hashes($hashref1,.'hashref1', $hashref2, .'hashref1',
$hashref3.'hashref1', );
and then in the sub use the even arguments as the hashref and the odd
arguments as the filename, but this strikes me as a problem that ought
not to be a problem.
Thanks, CC.
------------------------------
Date: Wed, 29 Feb 2012 18:36:52 +0100
From: Kiuhnm <kiuhnm03.4t.yahoo.it>
Subject: Re: access to variable names inside subprocedure
Message-Id: <4f4e6232$0$1389$4fafbaef@reader1.news.tin.it>
On 2/29/2012 17:35, ccc31807 wrote:
> Question: I would like to access the string value of the variable
> names passed as arguments to a sub inside the sub.
>
> The following stores a hash in a file named like
> 'HASH(0xdeadbeef).dat' but I would like to store the hash in a file
> named like 'hashref1.dat'.
>
> use Storable;
> my $hashref1 = retrieve('hashref1.dat');
> my $hashref2 = retrieve('hashref2.dat');
> my $hashref3 = retrieve('hashref3.dat');
> # extensive processing on $hashref1, $hashref2, and $hashref3
> # ... then
> save_hashes($hashref1, $hashref2, $hashref3);
> exit(0);
>
> sub save_hashes
> {
> foreach my $hashref (@_)
> {
> my $filename = sprintf("%s.dat", $hashref);
> store($hashref, $filename);
> }
> }
>
>
> I can do it by passing the arguments twice, once as a string and the
> second time as a variable, like this:
>
> save_hashes($hashref1,.'hashref1', $hashref2, .'hashref1',
> $hashref3.'hashref1', );
>
> and then in the sub use the even arguments as the hashref and the odd
> arguments as the filename, but this strikes me as a problem that ought
> not to be a problem.
The problem is that a variable doesn't know its name. You use its name
*in the code* to refer to it. As far as I know, that name is lost at
runtime. Here's a workaround:
--->
...
save_hashes(qw/hashref1 hashref2 hashref3/);
sub save_hashes
{
foreach my $hashName (@_)
{
my $filename = sprintf("%s.dat", $hashName);
store(eval "\$$hashName", $filename);
}
}
<---
Can you see why it works?
If $hashName contains the string 'hashref1', then
eval "\$$hashName"
is equivalent to
eval '$hashref1'
because $hashName gets interpolated, being double-quoted.
Kiuhnm
------------------------------
Date: Wed, 29 Feb 2012 11:44:09 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: access to variable names inside subprocedure
Message-Id: <4f4e63e9$0$75674$815e3792@news.qwest.net>
On 02/29/12 10:35, ccc31807 wrote:
> Question: I would like to access the string value of the variable
> names passed as arguments to a sub inside the sub.
>
> The following stores a hash in a file named like
> 'HASH(0xdeadbeef).dat' but I would like to store the hash in a file
> named like 'hashref1.dat'.
That's saying that the data is a hash, to see the data:
use Data::Dumper;
>
> use Storable;
> my $hashref1 = retrieve('hashref1.dat');
> my $hashref2 = retrieve('hashref2.dat');
> my $hashref3 = retrieve('hashref3.dat');
> # extensive processing on $hashref1, $hashref2, and $hashref3
> # ... then
> save_hashes($hashref1, $hashref2, $hashref3);
> exit(0);
>
> sub save_hashes
> {
> foreach my $hashref (@_)
> {
> my $filename = sprintf("%s.dat", $hashref);
> store($hashref, $filename);
> }
> }
>
>
> I can do it by passing the arguments twice, once as a string and the
> second time as a variable, like this:
>
> save_hashes($hashref1,.'hashref1', $hashref2, .'hashref1',
> $hashref3.'hashref1', );
>
> and then in the sub use the even arguments as the hashref and the odd
> arguments as the filename, but this strikes me as a problem that ought
> not to be a problem.
save_hashes( hashref1 => $hashref1, etc. )
or
save_hashes( 'hashref1', $hashref1, etc. )
sub save_hashes
{
my %data = @_;
for my $fname ( keys %data )
{
etc...
}
}
'hashref1' is not a terribly helpful filename.
If 'hashref1' is in the data, then pass $hashref1 and pull the filename
from the data.
------------------------------
Date: Wed, 29 Feb 2012 09:54:58 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: access to variable names inside subprocedure
Message-Id: <d1d33b5e-362f-46e5-80b7-36dc8ee478db@1g2000yqv.googlegroups.com>
On Feb 29, 12:36=A0pm, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> The problem is that a variable doesn't know its name. You use its name
> *in the code* to refer to it. As far as I know, that name is lost at
> runtime. Here's a workaround:
>
> --->
> ...
> save_hashes(qw/hashref1 hashref2 hashref3/);
>
> sub save_hashes
> {
> =A0 =A0foreach my $hashName (@_)
> =A0 =A0{
> =A0 =A0 =A0my $filename =3D sprintf("%s.dat", $hashName);
> =A0 =A0 =A0store(eval "\$$hashName", $filename);
> =A0 =A0}}
>
> <---
>
> Can you see why it works?
Yes. The value of each element is a string, to which sprintf() appends
a '.dat'.
If the value of each element is a string, then to fool Perl into
thinking it's a scalar, you need to prepend the '$' sigil. But then
you need to eval() the string to get at the value.
I'm munging large data files to produce several different reports with
several different pages each. I don't really know the content of the
data, or the number of reports, or the number of pages, until I
process the data, and I have to remember each days data because the
files overwrite each day.
I can dynamically create the data structures, and dynamically populate
them with the appropriate values, but have spent most of the morning
trying to come up with a dynamic way to save the data structures.
I very much appreciate the help. Sometimes we are so wedded to a
particular paradigm that we cannot make the small shift that makes the
difference between success and failure. Yes, I can see how to move
from strings to variable names and values, and as you said, it appears
to be impossible to move from values to the names we have given them,
particularly when the values are a memory location.
Thanks, CC.
------------------------------
Date: Wed, 29 Feb 2012 10:57:41 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: access to variable names inside subprocedure
Message-Id: <db4beaf5-48fb-4a7c-9a36-aaa88b8b8291@r1g2000yqk.googlegroups.com>
On Feb 29, 12:44=A0pm, "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.
Data::Dumper isn't a solution for me except just to look at the
structure of the data structure. I don't care what the names are, as
the names are in the data. I spit out the reports doing something like
this:
open OUT, '>', $dynamically_generated_file_name or die $!;
foreach my $k1 (sort keys %{$hashref})
{ foreach my $k2 (sort keys %{$hashref->{$k1}})
{ foreach my $k3 (sort keys %{$hashref->{$k10{$k2}}})
{ print OUT qq("$k1","$k2","$k3","$hashref->{$k1}{$k2}
{$k3}"\n); } } }
close OUT;
I don't pretend to be expert at this, but it works and does what I
need, and the users that consume the output are happy -- so I guess I
am too.
CC.
------------------------------
Date: Wed, 29 Feb 2012 21:45:33 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: access to variable names inside subprocedure
Message-Id: <tsi229-a73.ln1@anubis.morrow.me.uk>
Quoth ccc31807 <cartercc@gmail.com>:
> Question: I would like to access the string value of the variable
> names passed as arguments to a sub inside the sub.
perldoc -q "variable name"
Come on, you've been here long enough to know that.
If you insist: PadWalker.
Ben
------------------------------
Date: Wed, 29 Feb 2012 14:57:45 -0800 (PST)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: access to variable names inside subprocedure
Message-Id: <55dc6cf1-6679-4a7f-a76f-603f2fcb631f@s13g2000yqe.googlegroups.com>
On Feb 29, 4:45=A0pm, 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.
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.
CC.
------------------------------
Date: Wed, 29 Feb 2012 15:15:02 +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 After A Decade!
Message-Id: <87aa41k6x5.fsf@sapphire.mobileactivedefense.com>
Xah Lee <xahlee@gmail.com> writes:
> A excerpt from the new book 〈Modern Perl〉, just published, chapter 4
> on “Operators”. Quote:
>
> «The associativity of an operator governs whether it evaluates from
> 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. »
>
> LOL. Looks like the perl folks haven't changed. Fundamentals of
> serious math got botched so badly.
>
> Let me explain the idiocy.
>
> It says “The associativity of an operator governs whether it evaluates
> from left to right or right to left.”. Ok, so let's say we have 2
> operators: a white triangle △ and a black triangle ▲. Now, by the
> perl's teaching above, let's suppose the white triangle is “right
> associative” and the black triangle is “left associative”. Now, look
> at this:
>
> 3 △ 6 ▲ 5
>
> seems like the white and black triangles are going to draw a pistol
> and fight for the chick 6 there. LOL.
As the perlop manpage would have told you,
Operator associativity defines what happens if a sequence of the same
operators is used one after another
Since this is not the case in your example, it doesn't seem to be
applicable here. Also, the Perl I'm aware doesn't have 'white
triangle' and 'black triangle' operators and it also doesn't have
operators of equal precedence and different associativity. It can't,
actually, since there would be no way to evaluate an expression like
the mock one you invented above. Lastly, that something happens to be
in one way or another way in the completely arbitrary set of rules and
conventions commonly referred to as 'mathematics' (an essentially
outdated write-only programming language dating back to the times
when humans had to perform computations themselves) doesn't mean it is
of any relevance anywhere else just because of this, no matter how
dear it might be to lots of people.
------------------------------
Date: Wed, 29 Feb 2012 00:09:16 -0800 (PST)
From: Xah Lee <xahlee@gmail.com>
Subject: New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots After A Decade!
Message-Id: <0078bbfb-5dfc-48fc-af1a-69de3cf15c3e@b1g2000yqb.googlegroups.com>
New Science Discovery: Perl Idiots Remain Idiots After A Decade!
A excerpt from the new book =E3=80=88Modern Perl=E3=80=89, just published, =
chapter 4
on =E2=80=9COperators=E2=80=9D. Quote:
=C2=ABThe associativity of an operator governs whether it evaluates from
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 evalua=
tes
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. Now, =
by the
perl's teaching above, let's suppose the white triangle is =E2=80=9Cright
associative=E2=80=9D and the black triangle is =E2=80=9Cleft associative=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.
Now, let me tell you what operator precedence is. First of all, let's
limit ourselfs to discuss operators that are so-called binary
operators, which, in our context, basically means single symbol
operator that takes it's left and right side as operands. Now, each
symbol have a =E2=80=9Cprecedence=E2=80=9D, or in other words, the set of o=
perators
has a order. (one easy way to think of this is that, suppose you have
n symbols, then you give each a number, from 1 to n, as their order)
So, when 2 symbols are placed side by side such as =E3=80=8C3 =E2=96=B3 6 =
=E2=96=B2 5=E3=80=8D, the
symbol with higher precedence wins. Another easy way to think of this
is that each operator has a stickiness level. The higher its level, it
more sticky it is.
the problem with the perl explanations is that it's one misleading
confusion ball. It isn't about =E2=80=9Cleft/right associativity=E2=80=9D. =
It isn't
about =E2=80=9Cevaluates from left to right or right to left=E2=80=9D. Wors=
e, the word
=E2=80=9Cassociativity=E2=80=9D is a math term that describe a property of =
algebra
that has nothing to do with operator precedence, yet is easily
confused with because it is a property about order of evaluation. (for
example, the addition function is associative, meaning: =E3=80=8C(3+6)+5 =
=3D
3+(6+5)=E3=80=8D.)
compare it with this:
=E3=80=88Perl =EF=BC=86 Python: Complex Numbers=E3=80=89
http://xahlee.org/perl-python/complex_numbers.html
and for a good understanding of functions and operators, see:
=E3=80=88What's Function, What's Operator?=E3=80=89
http://xahlee.org/math/function_and_operators.html
------------------------------
Date: Wed, 29 Feb 2012 13:08:53 +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: <4f4e1554$0$1385$4fafbaef@reader2.news.tin.it>
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 〈Modern Perl〉, just published, chapter 4
> on “Operators”. Quote:
>
> «The associativity of an operator governs whether it evaluates from
> 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. »
>
> LOL. Looks like the perl folks haven't changed. Fundamentals of
> serious math got botched so badly.
>
> Let me explain the idiocy.
>
> It says “The associativity of an operator governs whether it evaluates
> from left to right or right to left.”. Ok, so let's say we have 2
> operators: a white triangle △ and a black triangle ▲. Now, by the
> perl's teaching above, let's suppose the white triangle is “right
> associative” and the black triangle is “left associative”. Now, look
> at this:
>
> 3 △ 6 ▲ 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
2**3**4
only the fact the '**' is right associative will tell you that the order is
2**(3**4)
and not
(2**3)**4
I remind you that 2^(3^4) != (2^3)^4.
Kiuhnm
------------------------------
Date: Wed, 29 Feb 2012 17:18:24 +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: <4f4e4fce$0$1386$4fafbaef@reader1.news.tin.it>
On 2/29/2012 16:15, Rainer Weikusat wrote:
> [...] 'mathematics' (an essentially
> outdated write-only programming language dating back to the times
> when humans had to perform computations themselves) [...]
Theoretical Computer Science is a branch of mathematics. Are you saying
it is outdated?
Kiuhnm
------------------------------
Date: Wed, 29 Feb 2012 11:43:22 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 After A Decade!
Message-Id: <ubo3r.20367$kv1.9848@newsfe03.iad>
On Wed, 29 Feb 2012 00:09:16 -0800, Xah Lee wrote:
Personally, I think this whole issue of precedence in a programming
language is over-rated. It seems to me that grouping of any non-trivial
set of calculations should be done so as to remove any possible confusion
as to intent. It is one more obstacle to accidental errors in logic,
where you intend one thing, possibly overlook precedence, and get a
strange result.
Sure, mathematically it *should* go a particular way, and any programming
language *should* follow that. Still... they don't, and since they don't
it makes more sense to be really obvious what you meant to do.
As someone pointed out, a programming language is for humans; computers
don't need them. That being the case, it makes sense to keep things as
clear as possible.
--
It's OKAY -- I'm an INTELLECTUAL, too.
------------------------------
Date: Wed, 29 Feb 2012 16:44:33 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 After A Decade!
Message-Id: <RBs3r.1628$jU1.1339@newsfe08.iad>
On Wed, 29 Feb 2012 17:18:24 +0100, Kiuhnm wrote:
> On 2/29/2012 16:15, Rainer Weikusat wrote:
>> [...] 'mathematics' (an essentially
>> outdated write-only programming language dating back to the times when
>> humans had to perform computations themselves) [...]
>
> Theoretical Computer Science is a branch of mathematics. Are you saying
> it is outdated?
>
> Kiuhnm
Neither mathematics nor computer science is outdated. Such an assertion
is without merit.
Mathematics is not exclusively - nor even primarily - concerned with
computations.
--
Can anything be sadder than work left unfinished? Yes, work never begun.
------------------------------
Date: Wed, 29 Feb 2012 09:45:29 -0800 (PST)
From: namekuseijin <namekuseijin@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: <68375f71-c728-42eb-a096-9a8be05a4ca1@p21g2000yqm.googlegroups.com>
On Feb 29, 5:09=C2=A0am, Xah Lee <xah...@gmail.com> 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 published=
, chapter 4
> on =E2=80=9COperators=E2=80=9D. Quote:
>
> =C2=ABThe associativity of an operator governs whether it evaluates from
> 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 eval=
uates
> 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. Now=
, by the
> perl's teaching above, let's suppose the white triangle is =E2=80=9Cright
> associative=E2=80=9D and the black triangle is =E2=80=9Cleft associative=
=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.
>
> Now, let me tell you what operator precedence is. First of all, let's
> limit ourselfs to discuss operators that are so-called binary
> operators, which, in our context, basically means single symbol
> operator that takes it's left and right side as operands. Now, each
> symbol have a =E2=80=9Cprecedence=E2=80=9D, or in other words, the set of=
operators
> has a order. (one easy way to think of this is that, suppose you have
> n symbols, then you give each a number, from 1 to n, as their order)
> So, when 2 symbols are placed side by side such as =E3=80=8C3 =E2=96=B3 6=
=E2=96=B2 5=E3=80=8D, the
> symbol with higher precedence wins. Another easy way to think of this
> is that each operator has a stickiness level. The higher its level, it
> more sticky it is.
>
> the problem with the perl explanations is that it's one misleading
> confusion ball. It isn't about =E2=80=9Cleft/right associativity=E2=80=9D=
. It isn't
> about =E2=80=9Cevaluates from left to right or right to left=E2=80=9D. Wo=
rse, the word
> =E2=80=9Cassociativity=E2=80=9D is a math term that describe a property o=
f algebra
> that has nothing to do with operator precedence, yet is easily
> confused with because it is a property about order of evaluation. (for
> example, the addition function is associative, meaning: =E3=80=8C(3+6)+5 =
=3D
> 3+(6+5)=E3=80=8D.)
>
> compare it with this:
>
> =E3=80=88Perl =EF=BC=86 Python: Complex Numbers=E3=80=89http://xahlee.org=
/perl-python/complex_numbers.html
>
> and for a good understanding of functions and operators, see:
>
> =E3=80=88What's Function, What's Operator?=E3=80=89http://xahlee.org/math=
/function_and_operators.html
associativity of operators mean little in the Lisp world obviously, so
why was this posted here? Sorry, perl, python and emacs folks...
BTW, it's the same in javascript: it is so such that 2 + 3 + "4" is
"54" and "2" + 3 + 4 is "234". Blame weak typing and + overloading,
though it may be a blessing.
------------------------------
Date: Tue, 28 Feb 2012 20:00:59 -0800 (PST)
From: scripts examples <example.scripts@gmail.com>
Subject: sample scripts for solving euler problems
Message-Id: <3e493566-fd19-4feb-ab49-8861cad0ba9a@s13g2000yqe.googlegroups.com>
Got a web site setup for solving euler problems in python, perl,
ruby and javascript.
Feel free to give me any feedback, thanks.
------------------------------
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 3626
***************************************
