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

"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

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!

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.

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 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.