Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
New Science Discovery: Perl Idiots Remain Idiots After A Decade!New Science Discovery: Perl Idiots Remain Idiots After A Decade!
34 views
Skip to first unread message
Xah Lee
Feb 29, 2012, 3:09:16 AM2/29/12
to
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.
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 “precedence”, 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 「3 △ 6 ▲ 5」, 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 “left/right associativity”. It isn't
about “evaluates from left to right or right to left”. Worse, the word
“associativity” 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: 「(3+6)+5 =
3+(6+5)」.)
compare it with this:
〈Perl ＆ Python: Complex Numbers〉
http://xahlee.org/perl-python/complex_numbers.html
and for a good understanding of functions and operators, see:
〈What's Function, What's Operator?〉
http://xahlee.org/math/function_and_operators.html
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.
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 “precedence”, 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 「3 △ 6 ▲ 5」, 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 “left/right associativity”. It isn't
about “evaluates from left to right or right to left”. Worse, the word
“associativity” 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: 「(3+6)+5 =
3+(6+5)」.)
compare it with this:
〈Perl ＆ Python: Complex Numbers〉
http://xahlee.org/perl-python/complex_numbers.html
and for a good understanding of functions and operators, see:
〈What's Function, What's Operator?〉
http://xahlee.org/math/function_and_operators.html
Chiron
Feb 29, 2012, 6:43:22 AM2/29/12
to
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.
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.
Kiuhnm
Feb 29, 2012, 7:08:53 AM2/29/12
to
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.
> 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.
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
Rainer Weikusat
Feb 29, 2012, 10:15:02 AM2/29/12
to
Xah Lee <xah...@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,
> 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.
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.
Kiuhnm
Feb 29, 2012, 11:18:24 AM2/29/12
to
On 2/29/2012 16:15, Rainer Weikusat wrote:
> [...] 'mathematics' (an essentially
Theoretical Computer Science is a branch of mathematics. Are you saying
it is outdated?
Kiuhnm
> [...] '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
Chiron
Feb 29, 2012, 11:44:33 AM2/29/12
to
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.
namekuseijin
Feb 29, 2012, 12:45:29 PM2/29/12
to
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.
Xah Lee
Feb 29, 2012, 7:02:39 PM2/29/12
to
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.
to clarify, amend my original post, here's what's needed for binary
operator precedence:
① the symbols are ordered. (e.g. given a unique integer)
② each symbol is has either one of left-side stickness or right-side
stickness spec. (needed when adjacent symbols are the same.)
About the lisp case mentioned by Tim, e.g. in「(f a b c)」, whether it
means 「(f (f a b) c)」 or 「(f a (f b c))」 . 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
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.
to clarify, amend my original post, here's what's needed for binary
operator precedence:
① the symbols are ordered. (e.g. given a unique integer)
② each symbol is has either one of left-side stickness or right-side
stickness spec. (needed when adjacent symbols are the same.)
About the lisp case mentioned by Tim, e.g. in「(f a b c)」, whether it
means 「(f (f a b) c)」 or 「(f a (f b c))」 . 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
Shmuel Metz
Feb 29, 2012, 11:10:48 PM2/29/12
to
In <87aa41k...@sapphire.mobileactivedefense.com>, on 02/29/2012
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 spam...@library.lspace.org
at 03:15 PM, Rainer Weikusat <rwei...@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
>'mathematics' (an essentially outdated write-only programming
>language dating back to the times when humans had to perform
>computations themselves)
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 spam...@library.lspace.org
Shmuel Metz
Feb 29, 2012, 11:06:42 PM2/29/12
to
In <ubo3r.20367$kv1....@newsfe03.iad>, on 02/29/2012
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.
at 11:43 AM, Chiron <chir...@gmail.com> said:
>Sure, mathematically it *should* go a particular way,
No. Mathematically it should go the way that it is defined to go.
>Sure, mathematically it *should* go a particular way,
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.
way to go. RPN and the like have their place, but often are difficult
for real people to read.
Chiron
Feb 29, 2012, 11:52:27 PM2/29/12
to
On Wed, 29 Feb 2012 23:06:42 -0500, Shmuel (Seymour J.) Metz wrote:
> In <ubo3r.20367$kv1....@newsfe03.iad>, on 02/29/2012
> at 11:43 AM, Chiron <chir...@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
> In <ubo3r.20367$kv1....@newsfe03.iad>, on 02/29/2012
> at 11:43 AM, Chiron <chir...@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.
>
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.
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
Chiron
Mar 1, 2012, 12:07:47 AM3/1/12
to
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
> 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,
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.
Kiuhnm
Mar 1, 2012, 6:00:26 AM3/1/12
to
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.
> 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.
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
Rainer Weikusat
Mar 1, 2012, 9:40:58 AM3/1/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
> In <87aa41k...@sapphire.mobileactivedefense.com>, on 02/29/2012
> at 03:15 PM, Rainer Weikusat <rwei...@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
> In <87aa41k...@sapphire.mobileactivedefense.com>, on 02/29/2012
> at 03:15 PM, Rainer Weikusat <rwei...@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.
trouble you.
Shmuel Metz
Mar 1, 2012, 10:13:11 AM3/1/12
to
In <DuD3r.21706$cL.1...@newsfe17.iad>, on 03/01/2012
I'm treating him as he treats others.
>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"
A brilliant piece of work. I greatly enjoyed it and the reaction to
its disclosure.
I'm treating him as he treats others.
>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"
its disclosure.
Shmuel Metz
Mar 1, 2012, 10:07:15 AM3/1/12
to
In <fgD3r.7862$_63....@newsfe19.iad>, on 03/01/2012
>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.
No, it doesn't.
>I was referring to the placement of parentheses (or other
>groupings) to indicate to *humans* what the intended sequence
>of events was.
Operator precedence has the same purpose, and was around long before
computers. Quite often expressions exploiting operator precedence are
easier *for humans* to read than expressions involving deeply nested
parentheses.
>Mathematically,
Your exposure to Mathematics is too limited.
>and in any language with which I am familiar,
Your exposure to computer languages is too limited.
>the sequence: 2 + 6 / 3 will yield 4.
Try it in APL.
>Whenever there is *any* possibility of ambiguity, I see no reason
>not to clarify.
Even if doing so makes it harder to read? Since you keep referring to
Mathematics, I will point out that it is rare in Mathematics for
anybody to publish a complete proof. Minor steps are almost always
omitted to make for easier reading, and ambiguous shortcuts are used
in the expectation that the reader will understand what is meant.
>Back in the days when the way you wrote your code affected how it
>was compiled,
That would be the present.
>it made sense to rely heavily on language-specific
>features, thus saving a few bytes.
Those optimizations involved adding extraneous parentheses, not
omitting redundant parentheses.
>A few extra variables, if they help clarity, aren't going to hurt
>anything.
And if they harm clarity?
>Let the machine do the grunt work.
That's exactly what languages with operator precedence do.
>Pamper your readers (which in a few weeks or months might be you)
>and show exactly what you had in mind.
The two goals conflict.
>That's all I'm saying.
No; you're saying to use redundant parentheses, which conflicts with
other things you're saying.
at 04:52 AM, Chiron <chir...@gmail.com> said:
>Yes. That (the mathematically defined way) is a particular way, is
>it not?
No. There is no "the mathematically defined way".
>Yes. That (the mathematically defined way) is a particular way, is
>it not?
>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.
computers. Quite often expressions exploiting operator precedence are
easier *for humans* to read than expressions involving deeply nested
parentheses.
>Mathematically,
Your exposure to Mathematics is too limited.
>and in any language with which I am familiar,
>the sequence: 2 + 6 / 3 will yield 4.
>Whenever there is *any* possibility of ambiguity, I see no reason
>not to clarify.
Mathematics, I will point out that it is rare in Mathematics for
anybody to publish a complete proof. Minor steps are almost always
omitted to make for easier reading, and ambiguous shortcuts are used
in the expectation that the reader will understand what is meant.
>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.
omitting redundant parentheses.
>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.
other things you're saying.
Chiron
Mar 2, 2012, 2:27:58 AM3/2/12
to
On Wed, 29 Feb 2012 00:09:16 -0800, Xah Lee wrote:
Xah, you won't grow even an inch taller by cutting others down.
--
I joined scientology at a garage sale!!
Shmuel Metz
Mar 1, 2012, 4:11:35 PM3/1/12
to
In <87k4341...@sapphire.mobileactivedefense.com>, on 03/01/2012
adequacy.
at 02:40 PM, Rainer Weikusat <rwei...@mssgmbh.com> said:
>You obviously don't have any sense of humour.
Certainly I do; I laugh at pretentious loons with delusions of
>You obviously don't have any sense of humour.
adequacy.
Xah Lee
Mar 2, 2012, 8:12:20 AM3/2/12
to
On Mar 1, 3:00 am, Kiuhnm <kiuhnm03.4t.yahoo.it> wrote:
> 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).
> 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).
> 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.
how do they explain when 2 operators are adjacent e.g. 「3 △ 6 ▲ 5 」?
> 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.
do you happen to know some site that shows the relevant page i can
have a look?
thanks.
Xah
Kiuhnm
Mar 2, 2012, 9:15:08 AM3/2/12
to
On 3/2/2012 14:12, Xah Lee wrote:
> On Mar 1, 3:00 am, Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>> 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).
>
>
>> 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.
>
> how do they explain when 2 operators are adjacent e.g. 「3 △ 6 ▲ 5 」?
The same way you do, I guess. An operand that has operators on both
> On Mar 1, 3:00 am, Kiuhnm<kiuhnm03.4t.yahoo.it> wrote:
>> 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).
>
>
>> 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.
>
> how do they explain when 2 operators are adjacent e.g. 「3 △ 6 ▲ 5 」?
sides is operand of the operator of higher precedence.
For instance, in
3 * 4 + 6
4 is operand of * but not of +.
Indeed, the operands of + are 3*4 and 6.
> do you happen to know some site that shows the relevant page i can
> have a look?
Kiuhnm
Chiron
Mar 2, 2012, 9:17:18 AM3/2/12
to
On Thu, 01 Mar 2012 10:13:11 -0500, Shmuel (Seymour J.) Metz wrote:
> In <DuD3r.21706$cL.1...@newsfe17.iad>, on 03/01/2012
> at 05:07 AM, Chiron <chir...@gmail.com> said:
>
>>Hmm... maybe, instead of just ridiculing him,
>
> I'm treating him as he treats others.
OK.
> In <DuD3r.21706$cL.1...@newsfe17.iad>, on 03/01/2012
> at 05:07 AM, Chiron <chir...@gmail.com> said:
>
>>Hmm... maybe, instead of just ridiculing him,
>
> I'm treating him as he treats others.
>
>>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"
>
> A brilliant piece of work. I greatly enjoyed it and the reaction to its
> disclosure.
What always gets me is how so many people criticized Sokal for doing it,
>>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"
>
> A brilliant piece of work. I greatly enjoyed it and the reaction to its
> disclosure.
instead of soundly condemning the editor for not bothering to verify what
Sokal said. It's like the kid points out that the emperor has no
clothes, so they shoot the kid. Of course, in real life, that's exactly
what would happen, so I guess I shouldn't be too surprised...
--
It is a hard matter, my fellow citizens, to argue with the belly,
since it has no ears.
-- Marcus Porcius Cato
Shmuel Metz
Mar 2, 2012, 10:53:30 AM3/2/12
to
In <OD44r.17949$vo2....@newsfe07.iad>, on 03/02/2012
even persecuted. I agree that the criticism of Prof Sokal was
outrageous, but it was also predictable.
at 02:17 PM, Chiron <chir...@gmail.com> said:
>What always gets me is how so many people criticized Sokal for doing
>it,
Google for Omerta. It's common for whistle blowers to be chastised or
>What always gets me is how so many people criticized Sokal for doing
>it,
even persecuted. I agree that the criticism of Prof Sokal was
outrageous, but it was also predictable.
Chiron
Mar 2, 2012, 2:06:06 PM3/2/12
to
On Fri, 02 Mar 2012 10:53:30 -0500, Shmuel (Seymour J.) Metz wrote:
> In <OD44r.17949$vo2....@newsfe07.iad>, on 03/02/2012
> at 02:17 PM, Chiron <chir...@gmail.com> said:
>
>>What always gets me is how so many people criticized Sokal for doing it,
>
> Google for Omerta. It's common for whistle blowers to be chastised or
> even persecuted. I agree that the criticism of Prof Sokal was
> outrageous, but it was also predictable.
Yeah, omerta... I'm familiar with it. Talk and you're dead, and they put
> In <OD44r.17949$vo2....@newsfe07.iad>, on 03/02/2012
> at 02:17 PM, Chiron <chir...@gmail.com> said:
>
>>What always gets me is how so many people criticized Sokal for doing it,
>
> Google for Omerta. It's common for whistle blowers to be chastised or
> even persecuted. I agree that the criticism of Prof Sokal was
> outrageous, but it was also predictable.
a canary in your mouth (well, some folks do, anyway).
But of course you're right - it's a milder form of omerta. It's just so
misguided. Kill the messenger. Imprison the whistle-blower.
--
Imitation is the sincerest form of plagiarism.
Albert van der Horst
Mar 12, 2012, 7:27:25 AM3/12/12
to
In article <0078bbfb-5dfc-48fc...@b1g2000yqb.googlegroups.com>,
>chapter 4
>on =E2=80=9COperators=E2=80=9D. Quote:
>
>=C2=ABThe associativity of an operator governs whether it evaluates from
Associativity of operators is defined in mathematics.
(The same concept may be used in programming).
"left-associativity" and "right-associativity" are computer languages
concept and their definitions are not from mathematics.
Interestingly in mathematics associative means that it doesn't matter
whether you use (a.b).c or a.(b.c).
Using xxx-associativity to indicate that it *does* matter is
a bit perverse, but the Perl people are not to blame if they use
a term in their usual sense.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
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, =
>New Science Discovery: Perl Idiots Remain Idiots After A Decade!
>
>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
>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
>
>LOL. Looks like the perl folks haven't changed. Fundamentals of
>serious math got botched so badly.
You're confused.
>LOL. Looks like the perl folks haven't changed. Fundamentals of
>serious math got botched so badly.
Associativity of operators is defined in mathematics.
(The same concept may be used in programming).
"left-associativity" and "right-associativity" are computer languages
concept and their definitions are not from mathematics.
Interestingly in mathematics associative means that it doesn't matter
whether you use (a.b).c or a.(b.c).
Using xxx-associativity to indicate that it *does* matter is
a bit perverse, but the Perl people are not to blame if they use
a term in their usual sense.
Groetjes Albert
--
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Shmuel Metz
Mar 12, 2012, 8:40:56 AM3/12/12
to
In <m0rrt...@spenarnc.xs4all.nl>, on 03/12/2012
at 11:27 AM, Albert van der Horst <alb...@spenarnc.xs4all.nl> said:
>You're confused.
No, s/h/it is just an acephalic troll with delusions of adequacy.
>"left-associativity" and "right-associativity" are computer
>languages concept and their definitions are not from mathematics.
Don't confuse the google pest with facts.
at 11:27 AM, Albert van der Horst <alb...@spenarnc.xs4all.nl> said:
>You're confused.
No, s/h/it is just an acephalic troll with delusions of adequacy.
>"left-associativity" and "right-associativity" are computer
>languages concept and their definitions are not from mathematics.
Kiuhnm
Mar 12, 2012, 9:05:54 AM3/12/12
to
On 3/12/2012 12:27, Albert van der Horst wrote:
> Interestingly in mathematics associative means that it doesn't matter
> whether you use (a.b).c or a.(b.c).
> Using xxx-associativity to indicate that it *does* matter is
> a bit perverse, but the Perl people are not to blame if they use
> a term in their usual sense.
You may see it this way:
> Interestingly in mathematics associative means that it doesn't matter
> whether you use (a.b).c or a.(b.c).
> Using xxx-associativity to indicate that it *does* matter is
> a bit perverse, but the Perl people are not to blame if they use
> a term in their usual sense.
Def1. An operator +:SxS->S is left-associative iff
a+b+c = (a+b)+c for all a,b,c in S.
Def2. An operator +:SxS->S is right-associative iff
a+b+c = a+(b+c) for all a,b,c in S.
Def3. An operator +:SxS->S is associative iff it is both left and
right-associative.
Kiuhnm
Raymond Wiker
Mar 12, 2012, 2:20:26 PM3/12/12
to
Shmuel (Seymour J.) Metz <spam...@library.lspace.org.invalid> writes:
> In <m0rrt...@spenarnc.xs4all.nl>, on 03/12/2012
> at 11:27 AM, Albert van der Horst <alb...@spenarnc.xs4all.nl> said:
>
>>You're confused.
>
> No, s/h/it is just an acephalic troll with delusions of adequacy.
Another way to put it is to say that Xah is a legend in his
> at 11:27 AM, Albert van der Horst <alb...@spenarnc.xs4all.nl> said:
>
>>You're confused.
>
> No, s/h/it is just an acephalic troll with delusions of adequacy.
own mind.
Albert van der Horst
Mar 12, 2012, 3:00:30 PM3/12/12
to
In article <4f5df4b3$0$1375$4faf...@reader1.news.tin.it>,
I know, but what the mathematicians do make so much more sense:
(a+b)+c = a+(b+c) definition of associative.
Henceforth we may leave out the brackets.
Don't leave out the brackets if the operators if the operators is
not associative.
P.S. There is no need for the operators to be SxS->S.
For example a b c may be m by n, n by l, l by k matrices respectively.
>
>Kiuhnm
(a+b)+c = a+(b+c) definition of associative.
Henceforth we may leave out the brackets.
Don't leave out the brackets if the operators if the operators is
not associative.
P.S. There is no need for the operators to be SxS->S.
For example a b c may be m by n, n by l, l by k matrices respectively.
>
>Kiuhnm
Shmuel Metz
Mar 12, 2012, 4:20:22 PM3/12/12
to
In <m0scs...@spenarnc.xs4all.nl>, on 03/12/2012
conventions owe as much to History as they do to logical necessity.
The conventions aren't even the same from author to author, e.g.,
whether "field" implies Abelian.
at 07:00 PM, Albert van der Horst <alb...@spenarnc.xs4all.nl> said:
>I know, but what the mathematicians do make so much more sense:
Not really; Mathematical notation is a matter of convention, and the
>I know, but what the mathematicians do make so much more sense:
conventions owe as much to History as they do to logical necessity.
The conventions aren't even the same from author to author, e.g.,
whether "field" implies Abelian.
0 new messages