• Vegeta (19/19) Mar 14 2004 The D manual says:
• Ben Hinkle (19/37) Mar 14 2004 order
• Manfred Nowak (14/20) Mar 15 2004 Because that sentence is not ambiguous, it can not serve as an
• Stewart Gordon (20/25) Mar 15 2004 Yes. Consider the dependency tree:
• Stewart Gordon (22/38) Mar 15 2004 Oops, I stopped a bit short, there actually eight:
• Stewart Gordon (13/20) Mar 15 2004

Vegeta <lord.vegeta ica.luz.ve> writes:

The D manual says:
 Unless otherwise specified, the implementation is free to evaluate the
components of an expression in any order. It is an error to depend on order
of evaluation when it is not specified.

And

 a + b + c
        
 can be evaluated as (a + b) + c, a + (b + c), (a + c) + b, (c + b) + a,
etc. Parenthesis control operator precedence, parenthesis do not control
order of evaluation. 


Isn't this a problem with floating point operations. It is well known that
associative law doesn't hold for floating point numbers.

Does this mean floating point expresions in D should always include
parenthesis in order to ensure the order of execution of operations?

If I explicitly say
a + (b+c)

Does D always solve b+c first or it can rewrite it to (a+b) +c?


-- 
Fuera Chávez

"Ben Hinkle" <bhinkle4 juno.com> writes:

"Vegeta" <lord.vegeta ica.luz.ve> wrote in message
news:c329td$1gml$1 digitaldaemon.com...
 The D manual says:
  Unless otherwise specified, the implementation is free to evaluate the
 components of an expression in any order. It is an error to depend on

order
 of evaluation when it is not specified.

 And

  a + b + c

  can be evaluated as (a + b) + c, a + (b + c), (a + c) + b, (c + b) + a,
 etc. Parenthesis control operator precedence, parenthesis do not control
 order of evaluation.


 Isn't this a problem with floating point operations. It is well known that
 associative law doesn't hold for floating point numbers.

 Does this mean floating point expresions in D should always include
 parenthesis in order to ensure the order of execution of operations?

Usually it doesn't matter but you are right that
 1e-20 + (1 - 1)
and
 (1e-20 + 1) - 1
end up with different results. Personally I'd only add parens if you
know the quantities in the expression can have wildly different
exponents and there's a mix of addition and subtraction (or
mixed signs). By the way, if loss of precision is a problem for
your application check out gmp http://www.swox.com/gmp.
A while ago I started a D interface to gmp - I should clean that
up for the latest release of D.

 If I explicitly say
 a + (b+c)

 Does D always solve b+c first or it can rewrite it to (a+b) +c?

It should always solve b+c first. The sentance "Parenthesis control
operator precedence, parenthesis do not control order of evaluation."
means that the parens control the order of the additions but not
the order of evaluation of a, b and c. At least that's how I
interpret it :-)

 -- 
 Fuera Chávez

Manfred Nowak <svv1999 hotmail.com> writes:

Ben Hinkle wrote:

[...]
 Does D always solve b+c first or it can rewrite it to (a+b) +c?

 It should always solve b+c first. The sentance "Parenthesis control
 operator precedence, parenthesis do not control order of evaluation."
 means that the parens control the order of the additions but not
 the order of evaluation of a, b and c. At least that's how I
 interpret it :-)

Because that sentence is not ambiguous, it can not serve as an
argument for your interpretation in a whole ... and the served subpart is
trivial :-).

Uncertanty arises from the fact, that the first part of the cited
sentence does not contribute anything to the abc-example. There is only
a certain propability , that the author wanted to express, that
parentheses do control the evaluation of the subexpressions generated by
them, because otherwise the examples with parenthesis immideately
preceding the cited sentence would again not contribute anything to the
abc-example.

Anyhow the documentation should be fixed.

So long!

Stewart Gordon <smjg_1998 yahoo.com> writes:

Ben Hinkle wrote:

<snip>
 It should always solve b+c first. The sentance "Parenthesis control
 operator precedence, parenthesis do not control order of evaluation."
 means that the parens control the order of the additions but not
 the order of evaluation of a, b and c. At least that's how I
 interpret it :-)

Yes.  Consider the dependency tree:

  a+(b+c)
  /     \
a      b+c
        / \
       b   c

Any bottom-up topological sort of this tree is a valid evaluation order. 
  There are five possibilities in this case:

a b c b+c a+(b+c)
a c b b+c a+(b+c)
b a c b+c a+(b+c)
b c a b+c a+(b+c)
b c b+c a a+(b+c)

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.

Stewart Gordon <smjg_1998 yahoo.com> writes:

Stewart Gordon wrote:

<snip>
 Yes.  Consider the dependency tree:
 
  a+(b+c)
  /     \
 a      b+c
        / \
       b   c
 
 Any bottom-up topological sort of this tree is a valid evaluation order. 
  There are five possibilities in this case:
 
 a b c b+c a+(b+c)
 a c b b+c a+(b+c)
 b a c b+c a+(b+c)
 b c a b+c a+(b+c)
 b c b+c a a+(b+c)

Oops, I stopped a bit short, there actually eight:

c a b b+c a+(b+c)
c b a b+c a+(b+c)
c b b+c a a+(b+c)

What's more, a parallel machine opens up more options.  Using // for 
parallel and ~ for sequence, here are just a few examples.

Two processors:
(b // c) ~ (a // b+c) ~ a+(b+c)
(a // (b ~ c ~ b+c)) ~ a+(b+c)
((a ~ b) // c) ~ b+c ~ a+(b+c)

Three processors:
(a // b // c) ~ b+c ~ a+(b+c)
(a // ((b // c) ~ b+c)) ~ a+(b+c)

The best strategy depends on the relative evaluation costs of the 
subexpressions.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the 
unfortunate victim of intensive mail-bombing at the moment.  Please keep 
replies on the 'group where everyone may benefit.

Stewart Gordon <smjg_1998 yahoo.com> writes:

Vegeta wrote:

<snip>
 Isn't this a problem with floating point operations. It is well known
 that associative law doesn't hold for floating point numbers.
 
 Does this mean floating point expresions in D should always include 
 parenthesis in order to ensure the order of execution of operations?

<snip>

No, exactly as you said:

<stick>
 Parenthesis control operator precedence, parenthesis do not control 
 order of evaluation.

</stick>

If you need to control order of evaluation, use separate assignment 
statements.  If you need to control precedence, use parentheses.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.