[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jim Segrave
Subject: Re: [Bug-gnubg] wrong dice colours in html export and below board in GUI
Date: Fri, 28 Nov 2003 19:56:31 +0100
User-agent: Mutt/1.4i

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]