Author: José Carlos
Date: 17:00:25 07/01/04
Go up one level in this thread
On July 01, 2004 at 19:29:08, Dieter Buerssner wrote: >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. That might be the case when I last checked: bitwise operators. So, my mistake. Thanks for pointing it out. José 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.