Author: Dieter Buerssner
Date: 16:29:08 07/01/04
Go up one level in this thread
On July 01, 2004 at 18:43:21, José Carlos wrote: >On July 01, 2004 at 18:10:54, Robert Hyatt wrote: > >>On July 01, 2004 at 16:15:41, Dave Kuntzsch wrote: >> >>>In blitz tournaments I run, Crafty always seems to leave a lot of time on the >>>table at the end, so I took look at time.c to see if there was a reason. There I >>>ran across the 'USAGE' .rc parameter and decided to specify that as 50 in >>>crafty.rc. It made no difference at all. I took a closer look at the code and >>>saw this: >>>time_limit *= 1.0 + usage_level / 100.0; >>> >>>If the purpose is to increase the time limit by some percentage, shouldn't there >>>be parenthesis around the expression like this? >>>time_limit *= (1.0 + usage_level / 100.0); >>> >>>Please correct me if I'm wrong. >>> >>>Dave >> >>Nope. It is done as this >>usage/100. >> then result + 1.0 >> >>Then multiply time by that amount which can be between .5 and 1.5... >> >>It works for me regularly when I fiddle with this... > > I don't remember when I last tested this (I use the parenthesis since then), >but I'm quite sure it didn't work as you describe. IIRC, it was with VC++ 6.0. >Can't check it now, but I'll confirm tomorrow. Jose Carlos, this would be a very broken compiler (or another language than C :-). The precendece of operators is in the order in which they appear in Iso-C-Standard [Parentheses, and square brackets] 6.5.2 Postfix operators . . . . . . . . . . . . . . . . . . . 70 6.5.3 Unary operators . . . . . . . . . . . . . . . . . . . 78 6.5.4 Cast operators . . . . . . . . . . . . . . . . . . . . 82 6.5.5 Multiplicative operators . . . . . . . . . . . . . . . . 83 6.5.6 Additive operators . . . . . . . . . . . . . . . . . . 83 6.5.7 Bitwise shift operators . . . . . . . . . . . . . . . . . 85 6.5.8 Relational operators . . . . . . . . . . . . . . . . . . 86 6.5.9 Equality operators . . . . . . . . . . . . . . . . . . 87 6.5.10 Bitwise AND operator . . . . . . . . . . . . . . . . . 88 6.5.11 Bitwise exclusive OR operator . . . . . . . . . . . . . . 89 6.5.12 Bitwise inclusive OR operator . . . . . . . . . . . . . . 89 6.5.13 Logical AND operator . . . . . . . . . . . . . . . . . 89 6.5.14 Logical OR operator . . . . . . . . . . . . . . . . . . 90 6.5.15 Conditional operator . . . . . . . . . . . . . . . . . . 90 6.5.16 Assignment operators . . . . . . . . . . . . . . . . . 92 6.5.17 Comma operator . . . . . . . . . . . . . . . . . . . 94 61) The syntax specifies the precedence of operators in the evaluation of an expression, which is the same as the order of the major subclauses of this subclause, highest precedence first. Thus, for example, the expressions allowed as the operands of the binary + operator (6.5.6) are those expressions defined in 6.5.1 through 6.5.6. The exceptions are cast expressions (6.5.4) as operands of unary operators (6.5.3), and an operand contained between any of the following pairs of operators: grouping parentheses () (6.5.1), subscripting brackets [] (6.5.2.1), function-call parentheses () (6.5.2.2), and the conditional operator ?: (6.5.15). Within each major subclause, the operators have the same precedence. Left- or right-associativity is indicated in each subclause by the syntax for the expressions discussed therein. >>>time_limit *= 1.0 + usage_level / 100.0; So, divide (a multplicative operator) must come first, than the add, than the *= (an Assignment operator). I think, we can trust, that the C-compilers do this correctly. The precedence list is also rather intuitive, perhaps with the exception of the biwise operators. a == b&c is not a == (b&c) but rather (a == b) & c. Cheers, Dieter
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.