## D - Floating point order evaluation doubt

- Vegeta <lord.vegeta ica.luz.ve> Mar 14 2004
- "Ben Hinkle" <bhinkle4 juno.com> Mar 14 2004
- Manfred Nowak <svv1999 hotmail.com> Mar 15 2004
- Stewart Gordon <smjg_1998 yahoo.com> Mar 15 2004
- Stewart Gordon <smjg_1998 yahoo.com> Mar 15 2004
- Stewart Gordon <smjg_1998 yahoo.com> Mar 15 2004

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

Mar 14 2004

"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

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

Mar 14 2004

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

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!

Mar 15 2004

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.

Mar 15 2004

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.

Mar 15 2004

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?

No, exactly as you said: <stick>Parenthesis control operator precedence, parenthesis do not control order of evaluation.

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.

Mar 15 2004