Order of evaluation of expressions
Mark Jason Dominus
@s = qw(a b);
$z = shift(@s) . shift(@s);
print $z;
guaranteed to print "ab"?
Rafael Garcia-Suarez
I'm not sure what you're asking for. Guarantee across all perl (5) versions ?
Future, past or present ? Guaranteed by the "language spec" (whatever
this may be) ?
Currently, due to the way the optree is constructed and executed, and
due to the implementation of shift, I'd say that your snippet is
guaranteed to produce "ab". But don't rely on it. I don't think Perl 5
will ever show another behavior, but Ponie might, if the internal
optimizer finds it more convenient to evaluate the right side of concat
first.
--
Uniformity is not *NIX
Eric J. Roode
Hash: SHA1
m...@plover.com (Mark Jason Dominus) wrote in news:bhok6j$70f$1...@plover.com:
Yes. Unlike C, Perl's order-of-evaluation is well-defined.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0AmSWPeouIeTNHoEQKBeQCg+Q49AV+cfvYwnHNTFxenN5ktYOAAnjv+
aJGfREuPkOdtbWxNasYNnWz6
=oCju
-----END PGP SIGNATURE-----
Abigail
MCMXCIII in <URL:news:Xns93DAD6841E...@206.127.4.25>:
~~ -----BEGIN PGP SIGNED MESSAGE-----
~~ Hash: SHA1
~~
~~ m...@plover.com (Mark Jason Dominus) wrote in news:bhok6j$70f$1...@plover.com:
~~
~~ > Is this:
~~ >
~~ > @s = qw(a b);
~~ > $z = shift(@s) . shift(@s);
~~ > print $z;
~~ >
~~ > guaranteed to print "ab"?
~~ >
~~
~~ Yes. Unlike C, Perl's order-of-evaluation is well-defined.
Where is its order of evaluation documented? Where in the documentation
does it say that:
@a = (3, 4, 5);
$z = shift (@a) + shift (@a) * shift (@a);
print $z;
results in 23 being printed?
Abigail
--
my $qr = qr/^.+?(;).+?\1|;Just another Perl Hacker;|;.+$/;
$qr =~ s/$qr//g;
print $qr, "\n";
Purl Gurl
> Eric J. Roode wrote:
> > mjd wrote:
> > > Is this:
> > > @s = qw(a b);
> > > $z = shift(@s) . shift(@s);
> > > print $z;
> > > guaranteed to print "ab"?
> > Yes. Unlike C, Perl's order-of-evaluation is well-defined.
> Where is its order of evaluation documented? Where in the documentation
> does it say that:
> @a = (3, 4, 5);
> $z = shift (@a) + shift (@a) * shift (@a);
> print $z;
> results in 23 being printed?
Quite predictable and in keeping with precedence.
Purl Gurl
--
#!perl
@a = (3, 4, 5);
$z = shift (@a) + shift (@a) * shift (@a);
print $z;
print "\n\n";
@a = (3, 4, 5);
$z = (shift (@a) + shift (@a)) * shift (@a);
print $z;
PRINTED RESULTS:
________________
23
35
nob...@mail.com
> Mark Jason Dominus wrote in comp.lang.perl.misc :
> > Is this:
> >
> > @s = qw(a b);
> > $z = shift(@s) . shift(@s);
> > print $z;
> >
> > guaranteed to print "ab"?
>
> I'm not sure what you're asking for.
Hmmm... look who's asking.
> Guarantee across all perl (5) versions ?
> Future, past or present ? Guaranteed by the "language spec" (whatever
> this may be) ?
I suspect that MJD is asking precisely to bring to the fore the fact
that the "language spec" (whatever that may be) currently doesn't
comment one way or the other.
Some people will interpret this has meaning it may change in future.
Other people will interpret this as meaning the "intuative" order is
guaranteed.
And, true to form, our resident troll will make nonsensical assertions
about how the intuative order is logically implied by presidence.
> Currently, due to the way the optree is constructed and executed, and
> due to the implementation of shift, I'd say that your snippet is
> guaranteed to produce "ab". But don't rely on it. I don't think Perl 5
> will ever show another behavior, but Ponie might, if the internal
> optimizer finds it more convenient to evaluate the right side of concat
> first.
I'd like to see the "language spec" (whatever that may be) make a
statement one way or the other.
Making it defined will reduce the scope for optomisations in Ponie.
Making it undefied will break a lot of existing code.
Not an easy choice.
Of course there are many more complex examples... see:
Message-ID: <u965stk...@wcl-l.bham.ac.uk>
http://groups.google.com/groups?selm=u965stkxuk.fsf%40wcl-l.bham.ac.uk
Purl Gurl
> Rafael Garcia-Suarez wrote:
> > Mark Jason Dominus wrote:
(snipped)
> And, true to form, our resident troll will make nonsensical assertions
"has made"
> about how the intuative order is logically implied by presidence.
"intuitive"
"how intuitive order"
"precedence"
> Making it defined will reduce the scope for optomisations in Ponie.
"optimization" "optimisation"
"reduce scope for optimization with"
> Making it undefied will break a lot of existing code.
"undefined"
Clearly you are not well educated in mathematics nor in spelling.
Equally clear, your reading comprehension skills and your relative
cognitive processing level, remain at grammar school level.
Your use of a personal insult is a clear marker of a lack of maturity.
An immature functional illiterate is not a person usually taken seriously.
( )
==\ __ __[oo
\/ /\@
## l_____|
#### ll ll
###### LL LL
Purl Gurl
Michael P. Broida
>
> #!perl
>
> @a = (3, 4, 5);
> $z = shift (@a) + shift (@a) * shift (@a);
> print $z;
>
> print "\n\n";
>
> @a = (3, 4, 5);
> $z = (shift (@a) + shift (@a)) * shift (@a);
> print $z;
>
> PRINTED RESULTS:
> ________________
>
> 23
>
> 35
Good example. I was trying to come up with something
to show a non-intuitive precedence, but you got it.
Mike
Michael P. Broida
> ~~ > Is this:
> ~~ >
> ~~ > @s = qw(a b);
> ~~ > $z = shift(@s) . shift(@s);
> ~~ > print $z;
> ~~ >
> ~~ > guaranteed to print "ab"?
> ~~ >
> ~~ Yes. Unlike C, Perl's order-of-evaluation is well-defined.
>
> Where is its order of evaluation documented? Where in the documentation
> does it say that:
> @a = (3, 4, 5);
> $z = shift (@a) + shift (@a) * shift (@a);
> print $z;
> results in 23 being printed?
Unless I'm missing something in your comment, it seems the question
boils down to "what precedence do subroutine/function calls have?"
I don't see "calls" specifically in the operator precedence listing at
the top of "perldoc perlop", but I think the highest priority "terms"
is what the function calls are in this case. Each function call was
evaluated in order left to right as "terms" of the larger expression,
THEN the multiply was done, THEN the addition was done.
This seems to fit the "perldoc perlop" description.
Mike
Purl Gurl
> Purl Gurl wrote:
(snipped)
> > @a = (3, 4, 5);
> > $z = shift (@a) + shift (@a) * shift (@a);
> > print $z;
> > @a = (3, 4, 5);
> > $z = (shift (@a) + shift (@a)) * shift (@a);
> > print $z;
> > PRINTED RESULTS:
> > 23
> > 35
> Good example. I was trying to come up with something
> to show a non-intuitive precedence, but you got it.
Are you being nice to compensate for your first article
directed at me, being a troll article?
Should you listen to Aunt Sally, as many here need to,
you will discover math is very intuitive.
Some of us learned Aunt Sally's math lessons as children.
http://www.mathnstuff.com/math/spoken/here/3essay/eooo.htm
Annoys me to read those arguing precedence order needs to
be defined. This is not the case with Perl being an English
based intuitive language. Those languages which do not follow
simple common sense or Aunt Sally's lessons, do need to be
defined and are languages of dubious quality.
If Perl's order of precedence was not well defined, intuitively,
this topic would have come up, many years back.
Purl Gurl
Eric J. Roode
Hash: SHA1
"Michael P. Broida" <michael....@boeing.com> wrote in
news:3F412BEA...@boeing.com:
> Unless I'm missing something in your comment, it seems the
> question boils down to "what precedence do subroutine/function
> calls have?"
No, not really. Precedence is different than order of evaluation. In C,
for example, precedence is well-defined, but order of evaluation is
famously undefined.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0E55WPeouIeTNHoEQKsYACg0X/4yuCnTu7pD7cqw0j6Kid9DQsAoN89
L0ZfvJcELWdN3q4IhNZl8Rfl
=FGbJ
-----END PGP SIGNATURE-----
Eric J. Roode
Hash: SHA1
Abigail <abi...@abigail.nl> wrote in
news:slrnbk10md....@alexandra.abigail.nl:
> Eric J. Roode (REMOVE...@comcast.net) wrote on MMMDCXXXIX
> September MCMXCIII in
> <URL:news:Xns93DAD6841E...@206.127.4.25>: ~~ -----BEGIN
> PGP SIGNED MESSAGE----- ~~ Hash: SHA1
> ~~
> ~~ m...@plover.com (Mark Jason Dominus) wrote in
> news:bhok6j$70f$1...@plover.com: ~~
> ~~ > Is this:
> ~~ >
> ~~ > @s = qw(a b);
> ~~ > $z = shift(@s) . shift(@s);
> ~~ > print $z;
> ~~ >
> ~~ > guaranteed to print "ab"?
> ~~ >
> ~~
> ~~ Yes. Unlike C, Perl's order-of-evaluation is well-defined.
>
>
> Where is its order of evaluation documented? Where in the
> documentation does it say that:
>
> @a = (3, 4, 5);
> $z = shift (@a) + shift (@a) * shift (@a);
> print $z;
>
> results in 23 being printed?
Well, I don't know. I could have sworn that I either read it in some
authoritative place, or I heard some authority state it. But searching
through the docs, and searching online, I can't find anything to back up
my statement. I withdraw it.
Thanks for your nice warm fuzzy tone, Abigail.
I also should have noticed who was posing the question. MJD knows much
more about Perl, especially its internals, than I do. If I had noticed
that he was the one who had asked the question, I wouldn't have responded
with my quick, unresearched answer; MJD certainly has as many or more
resources and history of Perl knowledge as myself.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0E7HWPeouIeTNHoEQJ7hACeNY/pVLoGaPyX5PTTrlD0fymLMlwAoIsL
KIJXOu+HZbq2hmjlHs5PL2js
=UYis
-----END PGP SIGNATURE-----
Eric J. Roode
Hash: SHA1
Purl Gurl <purl...@purlgurl.net> wrote in news:3F408AF4.64C88572
@purlgurl.net:
>
> Quite predictable and in keeping with precedence.
True, but a couple of quick examples does not prove that Perl's precedence
is well-defined.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0E7aWPeouIeTNHoEQIDxgCg37TORAi1xpN9NK1duUrQYO6B8J0Anj/2
s1cQ1ZvOujiJbOzvRLGU2Bjc
=QxTG
-----END PGP SIGNATURE-----
Eric J. Roode
Hash: SHA1
nob...@mail.com wrote in
news:4dafc536.03081...@posting.google.com:
> I'd like to see the "language spec" (whatever that may be) make a
> statement one way or the other.
>
> Making it defined will reduce the scope for optomisations in Ponie.
>
> Making it undefied will break a lot of existing code.
>
> Not an easy choice.
In my humble opinion, as a long-time C and Perl programmer, the language
ought to specify order of evaluation. Imho, it is one of C's great
weaknesses and sources of confusion that it does not define the OOE. This
is a huge confusion for many new programmers, and a continually recurring
theme on comp.lang.c (at least, it had been for years when I stopped
reading c.l.c a couple years ago).
If Perl does not currently guarantee OOE, I would vote that it should. The
potential gain in local platform-dependent optimization is not worth the
non-portability and confusion. My two cents.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0E8RGPeouIeTNHoEQKGvQCfb09TbFi7fGlIen1zJpfHVYvl61AAoIsu
fop/Vi2oQzOCniaux9OIwpk8
=p2Pn
-----END PGP SIGNATURE-----
Purl Gurl
> Michael P. Broida wrote:
(snipped)
> > Unless I'm missing something in your comment, it seems the
> > question boils down to "what precedence do subroutine/function
> > calls have?"
> No, not really. Precedence is different than order of evaluation. In C,
> for example, precedence is well-defined, but order of evaluation is
> famously undefined.
This is a myth born of differences in compilers.
Precedence in C is well defined and order of evaluation is
set, very strictly, by operator binding precedence.
It is when a programmer messes up binding precedence problems
come about, aggravated by how each C compiler handles code.
I am sure this "programmer quirk" can be deliberately exemplified
with Perl code, being C based. Still, this is a "programmer problem"
not a problem with perl core precedence / evaluation definition.
Should evaluation precedence be well defined, operator binding
precedence could not be defined. Having operator binding precedence
defined allows greater flexibility in "arrangement" of code.
Here are some articles which will enlighten some,
http://www.andromeda.com/people/ddyer/top-ten-supplement.html#evaluation-order
Purl Gurl
Purl Gurl
> Purl Gurl wrote:
(context removed by Roode)
(topic is Perl following classic mathematical order of evaluation)
> > Quite predictable and in keeping with precedence.
> True, but a couple of quick examples does not prove that Perl's precedence
> is well-defined.
Your comment infers you know of code which proves
Perl's precedence order is not defined.
Purl Gurl
Purl Gurl
> Eric J. Roode wrote:
> > Michael P. Broida wrote:
(snipped)
> > for example, precedence is well-defined, but order of evaluation is
> > famously undefined.
> This is a myth born of differences in compilers.
> Precedence in C is well defined and order of evaluation is
> set, very strictly, by operator binding precedence.
> flexibility in "arrangement" of code.
> Here are some articles which will enlighten some,
What should be intuitive to all, is evaluation order is
determined by how code is written, correctly or incorrectly.
See "Precedence" section near bottom of this page:
http://www.perl.com/pub/a/2000/12/p5pdigest/THISWEEK-20001217.html
Purl Gurl
Michael P. Broida
>
> Michael P. Broida wrote:
>
>
> > Good example. I was trying to come up with something
> > to show a non-intuitive precedence, but you got it.
>
> Are you being nice to compensate for your first article
> directed at me, being a troll article?
No,
1) it wasn't a troll article; you never did
understand the point of my post,
2) it was a genuine compliment for saving me the
time trying to come up with an illustration
of a sufficiently complex precedence case,
3) haven't you ever received enough compliments to
gracefully accept them?
> Should you listen to Aunt Sally, as many here need to,
> you will discover math is very intuitive.
> Some of us learned Aunt Sally's math lessons as children.
Without ever hearing of "Aunt Sally", I discovered that
basic math is intuitive 40 years ago; then I proceeded
to get my degrees in Mathematics and Computer Science.
In the course of that, I found that there is a LOT of
"higher" math that is not AT ALL intuitive. Rings, fields,
the "math of math", etc, take quite a bit of brain-twisting
to get to the right viewpoint to understand them.
However, computer language operator precedence is not ALWAYS
the same as mathematical operator precedence. (Many of the
computer language operators don't even exist in mathematics.)
SOME older languages didn't have such things as operator
precedence; it was all "left-to-right", when they allowed
more than one operation in a single statement.
Also, (in case you hadn't noticed) computer expressions don't
make valid mathematical equations. "a = a+1" is invalid math
(at least in the basic sense) yet works quite nicely in many
(most?) computer languages.
> Annoys me to read those arguing precedence order needs to
> be defined.
I wasn't arguing that at all. Read my post. The first
thing I did was go to "perldoc perlop" and see the
precedence order description right at the top. Looks
to me like it's defined very well.
> If Perl's order of precedence was not well defined, intuitively,
> this topic would have come up, many years back.
Yet this topic HAS come up, over and over again, as new
people try to use Perl (or any other language that they
don't take the time to "learn" from the bottom up).
Mike
Purl Gurl
> Purl Gurl wrote:
> > Eric J. Roode wrote:
> > > Michael P. Broida wrote:
(snipped)
> > set, very strictly, by operator binding precedence.
several years back.
His code:
$x = 10;
print ++$x / $x;
Pinyan's code produces what would be intuitively expected.
However, when a programmer messes up operator binding precedence,
then a problem comes about. This is not a problem with evaulation
order but rather a problem with a programmer not paying attention
to operator binding precedence.
In math, there are additional symbols, such as, [ ] and { }
which obviously cannot be used, directly, for Perl math; they
are already used elsewhere. This is also a commentary on how
Perl is running out of operand symbols, unless high ASCII is
put to use.
So, to expect evaluation order to work perfectly regardless
of code syntax, is ludricous. Easy enough to perform math
in your head or with pencil and paper. However, in programming
coding practices, good coding practices, are a programmer task,
not a task for perl core to handle.
Strikes me you boys are discussing Artificial Intelligence
rather than true programming. AI would know what to do. We,
as programmers, are expected to know what to do to prevent
compilation problems.
Purl Gurl
--
Look close at my last two syntax and results. They are
precisely as expected being free of binding precedence
problems inflicted in other code examples.
#!perl
$x = 10;
print ++$x / $x;
print "\n";
$x = 10;
print $x++ / $x;
print "\n";
$x = 10;
print ++$x / --$x;
print "\n";
$x = 10;
print $x++ / $x--;
print "\n";
$x = 10;
print --$x / ++$x;
print "\n";
$x = 10;
print $x-- / $x++;
print "\n";
$x = 10;
print ++$x + $x;
print "\n";
$x = 10;
print $x++ + $x;
PRINTED RESULTS:
________________
1
0.909090909090909
1
0.909090909090909
1
1.11111111111111
22
21
Mark Jason Dominus
<nob...@mail.com> wrote:
>I suspect that MJD is asking precisely to bring to the fore the fact
>that the "language spec" (whatever that may be) currently doesn't
>comment one way or the other.
Actually, I was asking because I thought I remembered that it did, or
else that the consensus on P5P was that it was an undocumented
guaranteed feature, or else that Larry had said something along those
lines, but I couldn't remember which, if any, of those things were real.
Mark Jason Dominus
Abigail <abi...@abigail.nl> wrote:
>Where is its order of evaluation documented? Where in the documentation
>does it say that:
Yes, that's what I would like to know.
Or, if it doesn't say that, I would like to know that it doesn't.
Does anyone have any actual facts?
I wasn't able to find anything about it in the manuals, but the
manuals are pretty badly organized on basic matters like this, so I'm
not sure I was looking in the right places.
Michael P. Broida
>
> "Michael P. Broida" <michael....@boeing.com> wrote in
> news:3F412BEA...@boeing.com:
>
> > Unless I'm missing something in your comment, it seems the
> > question boils down to "what precedence do subroutine/function
> > calls have?"
>
> No, not really. Precedence is different than order of evaluation. In C,
> for example, precedence is well-defined, but order of evaluation is
> famously undefined.
Ah, I -think- I see what you're saying. Maybe. <grin>
Thanks.
Mike
Michael P. Broida
>
> nob...@mail.com wrote in
> news:4dafc536.03081...@posting.google.com:
>
> > I'd like to see the "language spec" (whatever that may be) make a
> > statement one way or the other.
> >
> > Making it defined will reduce the scope for optomisations in Ponie.
> >
> > Making it undefied will break a lot of existing code.
> >
> > Not an easy choice.
>
> In my humble opinion, as a long-time C and Perl programmer, the language
> ought to specify order of evaluation. Imho, it is one of C's great
> weaknesses and sources of confusion that it does not define the OOE. This
> is a huge confusion for many new programmers, and a continually recurring
> theme on comp.lang.c (at least, it had been for years when I stopped
> reading c.l.c a couple years ago).
>
> If Perl does not currently guarantee OOE, I would vote that it should. The
> potential gain in local platform-dependent optimization is not worth the
> non-portability and confusion. My two cents.
I always found that just breaking complex expressions down into
simpler expressions will guarantee the order you desire. Yes,
it makes for longer, more wordy, programs, but it will do EXACTLY
what you told it to do, without worrying about the language. :)
That's NOT to say that the language shouldn't specify and
guarantee some specific order. It's just that you can avoid
any potential ordering problems by making it explicit in the
extreme:
$a = $b + $c;
$a = $a * $z;
$a = $a - $x;
(For something THAT simple, I would keep it one line and use
parens to force the order I want, even if it matches the language.
The difference in the compile step is negligible.)
Not "pretty" or "elegant", but it can't be misordered by the
language processor. Even that prior example with "shift()" calls
can be broken down in the DESIRED order to avoid any possible
language ordering conflicts.
Mike
Tony Curtis
Precedence tells you how to construct the syntax tree for
e.g.
a + b * c
+
a * a + (b * c)
b c
as opposed to
*
+ c (a + b) * c
a b
Order of evaluation OTOH tells you in e.g. from the 2nd
interpretation:
a + b
whether "a" or "b" will be evaluated first (e.g. "a" may
contain a side-effect that touches "b") which is partly a
tree-walking consideration. We still know that (a + b)
will be evaluated in toto before the multiplication.
(Probably hideously over-simplified, compiler-writers take
pity on me :-)
hth
t
Michael P. Broida
No, YOU inferred. His comment may have IMPLIED. :)
Mike
danglesocket
and work with a lot of html
One of the 'quick and eas(ier)' ones' is HTML::TokeParser.
it may be one your system.
try:
perldoc HTML::TokeParser
or:
man HTML::TokeParser
or
perldoc HTML::Parser
if not you can find it on cpan.
__danglesocket__
Eric J. Roode
Hash: SHA1
Purl Gurl <purl...@purlgurl.net> wrote in
news:3F414028...@purlgurl.net:
> Eric J. Roode wrote:
>
>> Michael P. Broida wrote:
>
> (snipped)
>
>> > Unless I'm missing something in your comment, it seems the
>> > question boils down to "what precedence do subroutine/function
>> > calls have?"
>
>> No, not really. Precedence is different than order of evaluation.
>> In C, for example, precedence is well-defined, but order of
>> evaluation is famously undefined.
>
>
> This is a myth born of differences in compilers.
>
> Precedence in C is well defined and order of evaluation is
> set, very strictly, by operator binding precedence.
No, it is not. Per the ISO C standard, a compliant C compiler may in
general rearrange the order in which en expression is evaluated. For
example, in the C expression *++c = a * b, a C compiler might do any of
the following:
- Fetch c, increment it, store result back in c, fetch a, fetch b,
multiply them, store result in address pointed to by c.
- Fetch c, increment it, keep the value in a register, fetch b, fetch
a, multiply them, store result in address in register, store register in
c.
- Fetch a, fetch b, multiply them, fetch c, increment it, store
product in address pointed to by this incremented address, store new
address value in c.
- and many, many more permutations.
And that's just a simple example with no side effects. With side effects
within one pair of sequence points, things rapidly become undefined.
"In ISO C, if a single object is modified more than once between
successive sequence points, the result is undefined. According to this
rule, the value of the expression ++i*++i is undefined." -- Harbison &
Steele, 4ed, pp 228-229.
Also: "When evaluating the actual arguments in a function call, the order
in which the arguments and the function expression are evaluated is not
specified...." ibid, p 228.
> It is when a programmer messes up binding precedence problems
> come about, aggravated by how each C compiler handles code.
In the C expression ++i*++i, the precedence is clearly and unambiguously
specified: ++ is of higher precedence than *, so it is as though the
programmer had written (++i)*(++i). Both multiplication and prefix
increment associate right. This does NOT mean that the order of
evaluation is well-defined. That is, it is NOT true that the compiler
will necessarily evaluate the expression in this order:
Fetch i, increment it, store result back in i, remember i as temp1,
fetch i, increment it, store result back in i, remember i as temp2,
multiply temp1 by temp2 to get the result.
Or, to give a concrete example, suppose i starts off as 5. It is NOT
necessarily true that the result of the expression ++i*++i (following the
above steps) is 42 (six times seven), leaving i as 7.
> Here are some articles which will enlighten some,
...
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang
> 98/HTML/_clang_precedence_and_order_of_evaluation.asp
The article at this url states, "Order of operations is not defined by
the language." That said, this article, and the one at the following
url, use the term "order of evaluation" inconsistently, and in a manner
that is inconsistent with the usage in the ISO C standard. What they
apparently mean is synonymous with precedence plus associativity; that
is, how expressions are grouped, not the order in which they are
evaluated.
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang
> 98/HTML/_pluslang_order_of_evaluation.asp
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0F5PWPeouIeTNHoEQLprgCfTZjiSud0YpD7DbmkU91gIz5RRW0Anjmt
Pyes1toWj1Dpb08pXORk9Giv
=ssCh
-----END PGP SIGNATURE-----
Eric J. Roode
Hash: SHA1
Purl Gurl <purl...@purlgurl.net> wrote in
news:3F41410C...@purlgurl.net:
Pardon me, I mis-spoke. Perl's operator precedence is well-defined and
well-documented. I apologize.
However, that does not mean that Perl's order of evaluation is well-
defined. The examples you posted are consistent with the assumption that
Perl's order of evaluation parallels its operator precedence and
associativity, but they are but two examples. Perhaps there is a counter
example which shows that in some circumstances Perl's evaluation happens
in a different order. That is what I meant.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0F6dmPeouIeTNHoEQKgQACfZqacadZnzaxMNOCJwwPps/KydNsAoIRM
fJ8LxWR0h2TREToTthL7XCcg
=ikWD
-----END PGP SIGNATURE-----
Eric J. Roode
Hash: SHA1
"Michael P. Broida" <michael....@boeing.com> wrote in
news:3F414C63...@boeing.com:
> "Eric J. Roode" wrote:
>>
>> If Perl does not currently guarantee OOE, I would vote that it
>> should. The potential gain in local platform-dependent optimization
>> is not worth the non-portability and confusion. My two cents.
>
> I always found that just breaking complex expressions down into
> simpler expressions will guarantee the order you desire. Yes,
> it makes for longer, more wordy, programs, but it will do EXACTLY
> what you told it to do, without worrying about the language. :)
>
> That's NOT to say that the language shouldn't specify and
> guarantee some specific order. It's just that you can avoid
> any potential ordering problems by making it explicit in the
> extreme:
> $a = $b + $c;
> $a = $a * $z;
> $a = $a - $x;
- From Harbison & Steele, 4ed, p 227:
<blockquote>
To control the order of evaluation, the programmer can
use assignments to temporary variables. However, a good
optimizing compiler might even rearrange computations
such as this:
int temp1, temp2;
...
/* Compute q=(a+b)+(c+d), exactly that way. */
temp1 = a+b;
temp2 = c+d;
q = temp1 + temp2;
</blockquote>
> (For something THAT simple, I would keep it one line and use
> parens to force the order I want, even if it matches the
> language. The difference in the compile step is negligible.)
Once again, in a language such as C in which order of evaluation is not
defined, parentheses do *not* affect order of evaluation! They affect
precedence only.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0F7xGPeouIeTNHoEQKcsACgolRH5jZ54iYhdfh4gDLP6oHeDhwAnRVn
ckrsHx6MAAFEtV3k3fQ6BH55
=nkWs
-----END PGP SIGNATURE-----
John W. Krahn
Just going by perlop.pod, shift() is a named unary operator which has
lower precedence than . and . is left associative which would mean it
would evaluate the left side first. Correct me if I'm wrong. :-)
John
--
use Perl;
program
fulfillment
Abigail
<URL:news:3F417BDC...@acm.org>:
==
== Just going by perlop.pod, shift() is a named unary operator which has
== lower precedence than . and . is left associative which would mean it
== would evaluate the left side first. Correct me if I'm wrong. :-)
Precedence isn't the same as order of evaluation.
Abigail
--
srand 123456;$-=rand$_--=>@[[$-,$_]=@[[$_,$-]for(reverse+1..(@[=split
//=>"IGrACVGQ\x02GJCWVhP\x02PL\x02jNMP"));print+(map{$_^q^"^}@[),"\n"
Michael P. Broida
No, that's a decent explanation. Thanks.
Mike
John W. Krahn
>
> John W. Krahn (kra...@acm.org) wrote on MMMDCXL September MCMXCIII in
> <URL:news:3F417BDC...@acm.org>:
> ==
> == Just going by perlop.pod, shift() is a named unary operator which has
> == lower precedence than . and . is left associative which would mean it
> == would evaluate the left side first. Correct me if I'm wrong. :-)
>
> Precedence isn't the same as order of evaluation.
Yes I know. What I was trying to say is that the concatenation operator
is left associative so that:
shift(@a) . shift(@b) . shift(@c) . shift(@d)
will be always be evaluated as:
( ( shift(@a) . shift(@b) ) . shift(@c) ) . shift(@d)
unless you explicitly parenthesise the expression. So it should follow
that if shift(@a) . shift(@b) . shift(@c) is always evaluated before
shift(@d) and shift(@a) . shift(@b) is always evaluated before
shift(@c), shouldn't it follow that shift(@a) is evaluated before
shift(@b)?
Benjamin Goldberg
>
> Abigail wrote:
[snip]
> > Precedence isn't the same as order of evaluation.
>
> Yes I know. What I was trying to say is that the concatenation operator
> is left associative so that:
>
> shift(@a) . shift(@b) . shift(@c) . shift(@d)
>
> will be always be evaluated as:
>
> ( ( shift(@a) . shift(@b) ) . shift(@c) ) . shift(@d)
>
> unless you explicitly parenthesise the expression.
That's right.
> So it should follow that if shift(@a) . shift(@b) . shift(@c) is always
> evaluated before shift(@d) and shift(@a) . shift(@b) is always evaluated
> before shift(@c), shouldn't it follow that shift(@a) is evaluated before
> shift(@b)?
Who is saying that "shift(@a) . shift(@b) . shift(@c)" actually *IS*
always evaluated before "shift(@d)"? Maybe it is in current perls, but
AFAIK, it's NOT gauranteed to be so in the future.
Consider the following two bits of code:
$x{foo} ||= keys %x;
$y{foo} = keys %y;
Which side gets evaluated first? Remember, ||= and = are both right
associative. So what should $x{foo} and $y{foo} be?
--
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}
Eric J. Roode
Hash: SHA1
"John W. Krahn" <kra...@acm.org> wrote in
news:3F42BCBC...@acm.org:
> Abigail wrote:
>>
>> John W. Krahn (kra...@acm.org) wrote on MMMDCXL September MCMXCIII in
>> <URL:news:3F417BDC...@acm.org>:
>> ==
>> == Just going by perlop.pod, shift() is a named unary operator which
>> has == lower precedence than . and . is left associative which would
>> mean it == would evaluate the left side first. Correct me if I'm
>> wrong. :-)
>>
>> Precedence isn't the same as order of evaluation.
>
> Yes I know. What I was trying to say is that the concatenation
> operator is left associative so that:
>
> shift(@a) . shift(@b) . shift(@c) . shift(@d)
>
> will be always be evaluated as:
>
> ( ( shift(@a) . shift(@b) ) . shift(@c) ) . shift(@d)
Parentheses don't control order of evaluation. Associativity is more
related to precedence than to order of evaluation.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP0LX+2PeouIeTNHoEQLCngCg8JhjLtdgN8+m/TZx4YmG3nyVW/4AniIa
Ei0TcxPoCAipEY6BQF5wmt1O
=DvP3
-----END PGP SIGNATURE-----
Abigail
<URL:news:3F42BCBC...@acm.org>:
() Abigail wrote:
() >
() > John W. Krahn (kra...@acm.org) wrote on MMMDCXL September MCMXCIII in
() > <URL:news:3F417BDC...@acm.org>:
() > ==
() > == Just going by perlop.pod, shift() is a named unary operator which has
() > == lower precedence than . and . is left associative which would mean it
() > == would evaluate the left side first. Correct me if I'm wrong. :-)
() >
() > Precedence isn't the same as order of evaluation.
()
() Yes I know. What I was trying to say is that the concatenation operator
() is left associative so that:
()
() shift(@a) . shift(@b) . shift(@c) . shift(@d)
()
() will be always be evaluated as:
()
() ( ( shift(@a) . shift(@b) ) . shift(@c) ) . shift(@d)
()
() unless you explicitly parenthesise the expression. So it should follow
() that if shift(@a) . shift(@b) . shift(@c) is always evaluated before
() shift(@d) and shift(@a) . shift(@b) is always evaluated before
() shift(@c), shouldn't it follow that shift(@a) is evaluated before
() shift(@b)?
No, now you are confusing precedence and order of evaluation again.
Abigail
--
perl -we '$@="\145\143\150\157\040\042\112\165\163\164\040\141\156\157\164".
"\150\145\162\040\120\145\162\154\040\110\141\143\153\145\162".
"\042\040\076\040\057\144\145\166\057\164\164\171";`$@`'
Anno Siegel
Like you, I was never able to find a general commitment in the docs.
While Perl documentation is huge, and a moving target, I think it's
safe to say that it is silent about the point. I mean, *someone*
would have found it by now :)
Only some (few) operators are described individually as having left-right
evaluation order. Some that come to mind are the short-circuiting boolean
operators, the list- and comma operators (both ","), and (I think)
assignment ("="), though I'm not entirely sure of the latter.
The most consequential conclusion can probably be drawn from the
list operator: it guarantees that function arguments are evaluated
in order.
I know I'm following up late, but I thought I'd add my two cents.
Anno
Abigail
September MCMXCIII in <URL:news:bj7ace$kha$1...@mamenchi.zrz.TU-Berlin.DE>:
!! Mark Jason Dominus <m...@plover.com> wrote in comp.lang.perl.misc:
!! > In article <slrnbk10md....@alexandra.abigail.nl>,
!! > Abigail <abi...@abigail.nl> wrote:
!! > >Where is its order of evaluation documented? Where in the documentation
!! > >does it say that:
!! >
!! > Yes, that's what I would like to know.
!! > Or, if it doesn't say that, I would like to know that it doesn't.
!! >
!! > Does anyone have any actual facts?
!! >
!! > I wasn't able to find anything about it in the manuals, but the
!! > manuals are pretty badly organized on basic matters like this, so I'm
!! > not sure I was looking in the right places.
!!
!! Like you, I was never able to find a general commitment in the docs.
!! While Perl documentation is huge, and a moving target, I think it's
!! safe to say that it is silent about the point. I mean, *someone*
!! would have found it by now :)
!!
!! Only some (few) operators are described individually as having left-right
!! evaluation order. Some that come to mind are the short-circuiting boolean
!! operators, the list- and comma operators (both ","), and (I think)
!! assignment ("="), though I'm not entirely sure of the latter.
Where in the documentation do you read that about comma in list context?
Perlop says:
Comma Operator
Binary "," is the comma operator. In scalar context it
evaluates its left argument, throws that value away, then
evaluates its right argument and returns that value. This
is just like C's comma operator.
In list context, it's just the list argument separator,
and inserts both its arguments into the list.
which is explicite for the scalar case, but doesn't say anything about
evaluation order in list context. Elsewhere in the same manual page,
it is written:
In the absence of parentheses, the precedence of list
operators such as "print", "sort", or "chmod" is either
very high or very low depending on whether you are looking
at the left side or the right side of the operator. For
example, in
@ary = (1, 3, sort 4, 2);
print @ary; # prints 1324
the commas on the right of the sort are evaluated before
the sort, but the commas on the left are evaluated after.
which suggest that if there's an evaluation order, it's from right
to left!
Anno Siegel
Hmm... Your quote above is what I had in mind, but it doesn't say what
I thought it says about the comma as list separator.
Looking for other evidence, I found (in the Camel, p. 109)
Once a list operator starts chewing up comma-separated arguments,
the only things that will stop it are tokens...
which seems to imply a left-to-right progress, but that's about parsing,
not evaluation order. Also, the part has been reworded in the current
perldoc to avoid exactly the left-to-right suggestion. It now talks of
"all comma-separated expressions found there (the right side of a list
operator)".
> Elsewhere in the same manual page,
> it is written:
>
> In the absence of parentheses, the precedence of list
> operators such as "print", "sort", or "chmod" is either
> very high or very low depending on whether you are looking
> at the left side or the right side of the operator. For
> example, in
>
> @ary = (1, 3, sort 4, 2);
> print @ary; # prints 1324
>
> the commas on the right of the sort are evaluated before
> the sort, but the commas on the left are evaluated after.
>
> which suggest that if there's an evaluation order, it's from right
> to left!
I don't understand the argument in this bit of documentation. It would
print "1234", no matter in which order the three list elements are evaluated.
But I can't be bothered now. I must mourn for my lost belief in left-to-
right evaluation of (argument-)lists.
Anno
Bob Walton
> Mark Jason Dominus <m...@plover.com> wrote in comp.lang.perl.misc:
>
>>In article <slrnbk10md....@alexandra.abigail.nl>,
>>Abigail <abi...@abigail.nl> wrote:
>>
>>>Where is its order of evaluation documented? Where in the documentation
>>>does it say that:
>>>
>>Yes, that's what I would like to know.
>>Or, if it doesn't say that, I would like to know that it doesn't.
>>
>>Does anyone have any actual facts?
>>
>>I wasn't able to find anything about it in the manuals, but the
>>manuals are pretty badly organized on basic matters like this, so I'm
>>not sure I was looking in the right places.
>>
>
> Like you, I was never able to find a general commitment in the docs.
> While Perl documentation is huge, and a moving target, I think it's
> safe to say that it is silent about the point. I mean, *someone*
> would have found it by now :)
Hmmmmm...doesn't the "synopsis" table at the beginning of perlop define
operator precedence and evaluation order rather nicely and completely?
It appears to describe the observed behaviors of the operators, and
doesn't seem to contain any errors or omissions. That is what I refer
to when I have precedence or evaluation order issues.
...
> Anno
>
--
Bob Walton
Sam Holden
No. It defines associativity and precendence. It does not mention
order of evaluation.
--
Sam Holden
David Combs
>
>- From Harbison & Steele, 4ed, p 227:
>
><blockquote>
> To control the order of evaluation, the programmer can
> use assignments to temporary variables. However, a good
> optimizing compiler might even rearrange computations
> such as this:
>
> int temp1, temp2;
> ...
> /* Compute q=(a+b)+(c+d), exactly that way. */
> temp1 = a+b;
> temp2 = c+d;
> q = temp1 + temp2;
></blockquote>
>
>> (For something THAT simple, I would keep it one line and use
>> parens to force the order I want, even if it matches the
>> language. The difference in the compile step is negligible.)
>
>Once again, in a language such as C in which order of evaluation is not
>defined, parentheses do *not* affect order of evaluation! They affect
>precedence only.
From the zero-indentation of those last three lines,
I assume that it's *you* that's saying it, not Steele (or Harbison).
Your statement, that in C the parens do not force the
order of calculation to follow the paren's order and nesting,
that's so contrary to everything I've ever read about C
or any other language -- that I'm asking you (or someone)
to please say a bit more about it.
I mean, is that claim in the language-definition?
Or just in some (weird) compiler, but not in (many) others?
Or might it be an option *to* some compiler?
Or have I just been reading incorrectly, for years,
every ref I've seen to C (and other languages too, perhaps)?
*Very* puzzled (that I'm the first to follow-up on this post).
THANKS!
(and if I'm wrong, please accept, in advance, my apologies.)
David
David Combs
Michael P. Broida <michael....@boeing.com> wrote:
>Tony Curtis wrote:
>>
>> >> On Mon, 18 Aug 2003 21:48:51 GMT,
>> >> "Michael P. Broida" <michael....@boeing.com> said:
>>
>> > "Eric J. Roode" wrote:
>> >> "Michael P. Broida" <michael....@boeing.com>
>> >> wrote in news:3F412BEA...@boeing.com:
>> >>
>> >> > Unless I'm missing something in your comment, it
>> >> seems the > question boils down to "what precedence do
>> >> subroutine/function > calls have?"
>> >>
>> >> No, not really. Precedence is different than order of
>> >> evaluation. In C, for example, precedence is
>> >> well-defined, but order of evaluation is famously
>> >> undefined.
Earlier, I replied to an article in this thread
that I believed said that even with parentheses,
in C the compiler could legally rearrange even
that -- implied with that is that of course
the *algebraic* result came out the same.
(I sure hope it included the word "parentheses",
because that's what I based my unbelieving reply on.)
Anyway, woe to the fledgling numerical analyst
who codes:
z = a + b + c + d + e + f
, where, in alphebetical order (a-f) the
values are:
.00000000333
(same for b, c, d, and e)
3.0000000000
, where the size of the mantissa in the floating-point
word makes a difference, ie compared with it
being *calculated* in *this* order:
z = a + b + f + c + d + e
Worrying ahead of time about optimizers changing
the order on you, you'd have to write it, maybe,
like this:
z = (a + (b + (c + (d + (e + (f))))))
, at least in the case where, suppose, a is smallest (eg .00000001),
b is next smallest (eg .0000006), and so on.
If the compiler could freely screw *this* around, even
with the parens -- horrors.
(Now I'm hoping that I did misread that post!)
David
David Combs
>Hash: SHA1
>
>"John W. Krahn" <kra...@acm.org> wrote in
>news:3F42BCBC...@acm.org:
>
>> Abigail wrote:
>>>
>>> John W. Krahn (kra...@acm.org) wrote on MMMDCXL September MCMXCIII in
>>> <URL:news:3F417BDC...@acm.org>:
>>> ==
>>> == Just going by perlop.pod, shift() is a named unary operator which
>>> has == lower precedence than . and . is left associative which would
>>> mean it == would evaluate the left side first. Correct me if I'm
>>> wrong. :-)
>>>
>>> Precedence isn't the same as order of evaluation.
>>
>> Yes I know. What I was trying to say is that the concatenation
>> operator is left associative so that:
>>
>> shift(@a) . shift(@b) . shift(@c) . shift(@d)
>>
>> will be always be evaluated as:
>>
>> ( ( shift(@a) . shift(@b) ) . shift(@c) ) . shift(@d)
>
>Parentheses don't control order of evaluation. Associativity is more
>related to precedence than to order of evaluation.
THERE IT IS AGAIN, THAT STATEMENT! (this time not referring to C, though)
If true, I guess that in perl you cannot add up wildly-differently-sized
reals (er, numbers) (where you know which are big and which are small).
What, have to write separate assignment statements, each one
growing by the next one of a, b, c, d, etc, being thus forced
to recode the only *intuitively* numerical-analysisly-correct:
z = (a + (b + (c + (d + (e + (f))))))
David
Sam Holden
[snip order or evaluation and precendence being different]
>
> THERE IT IS AGAIN, THAT STATEMENT! (this time not referring to C, though)
>
> If true, I guess that in perl you cannot add up wildly-differently-sized
> reals (er, numbers) (where you know which are big and which are small).
>
> What, have to write separate assignment statements, each one
> growing by the next one of a, b, c, d, etc, being thus forced
> to recode the only *intuitively* numerical-analysisly-correct:
>
> z = (a + (b + (c + (d + (e + (f))))))
Associativity and prededence have almost *nothing* to do with order of
evaluation. The order of evaluation in that example is irrelevant (assuming
those letters represent single numeric values.
Order of evaluation comes in, when you do something like:
z = (a() + ((b() + (c() + (d() + (e() + (f())))))))
The result will be as expected, in that e() + f() will be calculated, and then
d() + <prior result> and so on and so on.
Order of evaluation defined the order in which the functions a(), b(), .. f()
will be called.
They could be called as they are needed, in which case e() and f() will be
called first, then d(), then c(), then b(), then a(). Or they all be called
before the calculation begins arbitrary order. Or some micture of the two.
Order of evaluation only matters when those function have side effect, or
when when things like a++ are used, which also have side effects.
So in the perl example from above with some modification to make the
side effects of the shift function matter:
*a = *b = *c = *c; #make the side effects matter...
@a = qw/a b c d/;
$first = (shift(@a) . (shift(@b) . (shift(@c) . shift(@d))));
@a = qw/a b c d/;
$second = shift(@c) . shift(@d);
$second = shift(@b) . $second;
$second = shift(@a) . $second;
print "first: $first; second: $second\n";
Both $first and $second use the same associativity and precedence. However,
they have different order of evaluations.
From the output I get perl is evaluating the shift()s from left to right,
even though the parenthesis mean it is calculating the result from right
to left.
The calculation will be done in the order indicated by the precendence
and parenthesis. However, the evaluation of the individual terms is done
in a different (possibly arbitrary or random) order. The evaluation of
individual terms can *not* affect the result, unless there are
*side effects*.
--
Sam Holden
Sam Holden
>
> So in the perl example from above with some modification to make the
Which I trimmed and hence isn't there...
> *a = *b = *c = *c; #make the side effects matter...
^^
Should be *d :
*a = *b = *c = *d;
Which I did when I tested the code, but failed to copy the modified code
back to my posting.
--
Sam Holden
Eric J. Roode
Hash: SHA1
dkc...@panix.com (David Combs) wrote in news:bje0cm$opb$1
@reader2.panix.com:
Yes, that was me.
> Your statement, that in C the parens do not force the
> order of calculation to follow the paren's order and nesting,
> that's so contrary to everything I've ever read about C
> or any other language -- that I'm asking you (or someone)
> to please say a bit more about it.
Sure.
I think the confusion here is that many people are using the fact that
parentheses *group* expressions to mean that the expressions must be
evaluated in some particular order.
Let's take a simple example, again in C:
a = b + c * d;
Let's further suppose that before this statement, a is 1, b is 2, c is 3,
and d is 4.
Someone who didn't know about precedence might think that the result
would be an assignment of 20 to a (b + c is 2 + 3 which is 5, multiplied
by 4 is 20). But of course multiplication has a higher precedence, so
the actual result is an assignment of 14 to a (c * d is 3 * 4 which is
12, added to 2 is 14).
Now it is clear that the multiplication must happen first, before the
addition. This is because of precedence (and associativity, although
that does not enter into this particular example). Right. Also, if you
use parentheses to regroup the expression:
a = (b + c) * d;
then it is now clear that the addition must happen first, before the
addition.
This is the source of the confusion, and why you think that parentheses
control order of evaluation. They do not. They override (or refine,
depending on how you want to look at it) the precedence of operations,
which does have some effect on the order in which the operators are
evaluated.
However: what is explicitly NOT guaranteed is the order of evaluation of
the expressions a, b, c, d. In the above examples they are simple
variables. Nothing about the C standard, nor 30 years of C's existence,
dictates anything about the order in which those variables are fetched
from memory.
So what?
Well, perhaps those variables are declared volatile, and map to I/O
devices. Which value gets fetched first could have a drastic effect on
the result of the expression. (Think of tied variables in Perl). Or to
take a more common example, let's change the expression slightly to:
a = b() + c() * d();
Now, as we have seen before, the result of the function call c() is first
multiplied by the result of the function call d(), and that product is
then added to the result of the function call b(). BUT: There is no --
absolutely NO -- guarantee or standard or rule as to which function gets
called first, second, or third. Perhaps the compiler looks at the
expression and sees that three calls are needed, and invokes b(), then
c(), then d(), then multiplies the (stored) results of c() and d(), then
adds the (stored) result of b(). Perhaps it invokes the functions in a
different order.
If the functions have side effects, and especially if they have side
effects that affect each other (note grammatically correct usage of
"affect" and "effect"!), then the results are, as explicitly stated by
the ANSI and ISO C standards, *undefined*.
Much has been made of this in the C newsgroups; see the comp.lang.c FAQ
entry about the expression "i = i++".
Now, how does this relate to Perl?
I had been under the impression that Perl's order of evaluation was well-
defined, but that impression seems to have been incorrect. As far as I
can tell, there is no defined O of E in Perl, so the same caveats above
seem to apply to the Perl language.
But I'm not sure.
- --
Eric
$_ = reverse sort $ /. r , qw p ekca lre uJ reh
ts p , map $ _. $ " , qw e p h tona e and print
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBP1qiUmPeouIeTNHoEQJy/ACgqu3wokJBFG1DXONvu+VToAavHaoAnA1q
nxf14p5AFoT9Sob4UciQyN06
=1I6d
-----END PGP SIGNATURE-----
Ilya Zakharevich
Eric J. Roode
<REMOVE...@comcast.net>], who wrote in article <Xns93DCE1251F...@206.127.4.25>:
> Parentheses don't control order of evaluation. Associativity is more
> related to precedence than to order of evaluation.
IIRC, C compiler would not rearrage floating point expressions using
associativity/distributivity. However, it may rearrange integer
expressions (since for integer types the associativity/distributivity
hold); or rearrange things due to commutativity.
Perl lacking any optimization lieves it out of question completely...
Hope this helps,
Ilya
David Combs
What I believe to be true is that when dealing
with *reals*, addition doesn't necessarily
commute, ie a + b doesn't necessairly equal b + a,
because of the limited precision of reals.
So, suppose you want to sum a bunch of reals, maybe 10% of them
"big", and 90% tiny, such that if you add a big and a tiny,
the tiny add-on never shows up, because it "falls off the end"
of the number of bits allocated for the characteristic and
mantessa (these terms might be incorrect, but I simply
mean the two numerical parts a real is represented by in
the computer (hardware) you are using).
So it's like you never added-on the tiny number, as far
as the result you get.
However, suppose you had *lots* of those tiny numbers,
and the result of adding *those* up gives you a result
several orders of magnitude larger than the typical
single tiny one.
Now, the calculation order makes all the difference!
If you add up the big numbers before you start adding on to
the thus-far sum the the tiny ones, no matter how many
gillions of them you add in (one by one), the sum never
changes, not even by one bit.
However, if you add them up smallest first, then
the tiny ones *do* get counted -- well, their *sum*
does, assuming that that sum has gotten to be large enough
as to not be shoved off the end by the following large
numbers.
Does what I'm trying to say come across at all?
Thanks,
David
Ilya Zakharevich
<dkc...@panix.com>], who wrote in article <bkdtkp$2j8$1...@reader2.panix.com>:
> What I believe to be true is that when dealing
> with *reals*, addition doesn't necessarily
> commute, ie a + b doesn't necessairly equal b + a,
> because of the limited precision of reals.
Of course it commutes. It is the associativity (a+b)+c = a+(b+c)
which breaks; this contributes if you want to sum more than 2 numbers.
[And of course associativity holds for "reals"; it is the floating
point arithmetic where it breaks. ;-]
Just a small clarification,
Ilya
Eric J. Roode
@reader2.panix.com:
> In article <Xns93EEEC3E82...@206.127.4.25>,
> Eric J. Roode <REMOVE...@comcast.net> wrote:
> ...
>
>
> What I believe to be true is that when dealing
> with *reals*, addition doesn't necessarily
> commute, ie a + b doesn't necessairly equal b + a,
> because of the limited precision of reals.
Offhand, I can't think of an example where this would be true. Can you
give an example?
David Combs
Eric J. Roode <REMOVE...@comcast.net> wrote:
>dkc...@panix.com (David Combs) wrote in news:bkdtkp$2j8$1
>@reader2.panix.com:
>
>> In article <Xns93EEEC3E82...@206.127.4.25>,
>> Eric J. Roode <REMOVE...@comcast.net> wrote:
>> ...
>>
>>
>> What I believe to be true is that when dealing
>> with *reals*, addition doesn't necessarily
>> commute, ie a + b doesn't necessairly equal b + a,
>> because of the limited precision of reals.
>
>Offhand, I can't think of an example where this would be true. Can you
>give an example?
Nope -- Ilya corrected "commute" to "associate".
d.
David Combs
So few understand what I (probably badly) said, although
Ilya did. It's to do with the limited precision of
reals, on computers.
Perhaps Ilya's post makes everything clear.
David
Ilya Zakharevich
David Combs
> So few understand what I (probably badly) said,
The famous example is calculate sum of 1/n in opposite orders, once
from large values to small ones, the second time from small values to
large ones:
perl -wle "$s=0; $s += 1/$_ for 1..1e7; print $s"
16.6953113658567
perl -wle "$s=0; $s += 1/(10000001 - $_) for 1..1e7; print $s"
16.6953113658599
Doing calculations with precision of 77 digits (with gp):
? \p75
realprecision = 77 significant digits (75 digits displayed)
? sum(X=1,10000000,1./X)
%2 = 16.6953113658598518153991189395404518842498697523730804627851359543562876569
As you can see, the second way gives a practically precise value
(doing printf '%.20f' gives 16.69531136585989017360, so the result is
100x times more precise).
The idea is that when you add a small number to a large one, very few
digits of the small number matter (you can think that the small number
is first "denormalized" to the magnitude of the large one, with binary
digits "out of range" thrown away); this does not matter if you do
this addition once, but if you increment by a small number millions of
times, these rounding errors accumulate.
In the second way of addition when you calculate $s += $a with a small
$a (i.e., a large 10000001 - $_), $s is much smaller than in the first
way (check it with a pencil and a piece of paper for the first several
terms). In consequence, the errors due to rounding $a when
denormalizing to the size of $s are much smaller.
Hope this helps,
Ilya