Re: [Bug-gnubg] wrong dice colours in html export and below board in GUI

[Jim Segrave]

On Fri 28 Nov 2003 (19:16 +0100), Petr Kadlec wrote:
> At 14:42 28.11.2003 +0100, you wrote:
> >In the above subclauses, multiplication and division are in the same
> >subclause, so there is no precedence there. This leaves the compiler
> >free to evaluate:
> >
> >3 * ss * DIE_WIDTH / 2 as any of:
> >
> >(3 * ss * DIE_WIDTH) / 2
> >(3 * ss) * (DIE_WIDTH / 2)
> >3 * (ss * DIE_WIDTH / 2)
> >
> >or to rearrange things at compile time:
> >
> >3 * DIE_WIDTH / 2 evaluated in any order, replaced with the constant
> >result which gets multiplied by ss at run time.
> >
> >Can we please insert parentheses where required to force the desired
> >evaluation (a comment as to why the parentheses are there would not go
> >amiss). Otherwise the above patch corrects the problem only courtesy
> >of the vagaries of the current compiler being used and could change if
> >another compiler or a later/earlier version of this compiler is used.
> 
> Hmmmm, I believe this is a big misunderstanding (IMHO). The terms of the 
> expressions may be evaluated in any order, but that is NOT THE SAME as the 
> associativity of the terms. Take e.g. an expression like this:
> 
> result = f1() * f2() / f3();
> 
> The cited clause of the C standard is saying only that the functions f1(), 
> f2(), f3() may be called in any (unspecified) order. BUT, the computation 
> of the result takes place from left to right (as * and / are 
> left-associative operators), like that:
> 
> temp = result_from_f1 * result_from_f2;
> result = temp / result_from_f3;
> 
> The parentheses do change the associativity, but they DO NOT change the 
> order of evaluation, so even they would not solve the mentioned problem, ...
> The only things that changes the order of evaluation are: special operators 
> that have their order of evaluation set (i.e. those mentioned -- function 
> call, &&, ||, ?:, comma), or split the evaluation to multiple statements.

You're right - I'd actually looked for anything in the section on
expressions which dealt with left and right associativity and missed
it, as it's buried in a footnote. Since I hadn't found it, I
incorrectly assumed that a compiler was free to choose any ordering
for subexpressions. If I'd thought about it a bit more, I would have
looked even closer, since it's necessary that it be specified to
prevent a/b*c being ambiguous. The cited clause does go a bit further
than you state, in that:

a/b*c + d*e/f
can be evaluated by computing (d*e)/f, then (a/b)*c, then adding the
intermediate results.

But at any rate, it is not strictly necessary to parenthesise the
expression which started this digression, although it would be a wise
idea (in my opinion).


-- 
Jim Segrave           address@hidden