Author: Uri Blass
Date: 22:18:51 03/29/01
Go up one level in this thread
On March 29, 2001 at 18:47:45, Bertil Eklund wrote: >On March 29, 2001 at 18:13:02, Ralf Elvsén wrote: > >>On March 29, 2001 at 14:28:29, Uri Blass wrote: >> >>>On March 29, 2001 at 12:30:23, Ralf Elvsén wrote: >>> >> >>>> >>>>See my reply to Bertil below. The program might know it is losing >>>>but is forced to play the move anyway. Not the kind of rules I like. >>>> >>>>Ralf >>> >>>In tournament time control it may play the same move because it even has not >>>enough time to know that it is losing so it does not change the fact that the >>>level of game is higher than tournament time control. >>> >>>You can also ask the same question about a regular tournament game. >>>If you see at move 40 that you are losing and you have only few seconds to the >>>time control. >> >>The argument is moot since that is a singular event. Besides, if a program >>has as a part of its time management to not save up panic time before >>the time control it should be punished for it, and it will be in a regular >>game. The quality of time mangement for the two programs in Lykkes game >>is short circuited by this kind of "time control". >>> >>>I will prefer to play a move that I have not enough time to analyze in this case >> >>What do you mean? Play the move you think looks bad but you don't know >>how bad, or pick another move you don't know how good/bad it is? >>If you mean the last alternative, the programs aren't even doing this >>I guess. >> >>Let me try once more to explain what I mean: If Lykke for every 5th >>move produced a random integer between 1 and 64 and from that got >>a square and, if that square was occupied, removed that piece (not >>a king), it would introduce a random element which has nothing to do >>with chess. And it wouldn't favor one program over another. But to >>me it would make the game less interesting. >> >>Now he is forcing the program to play a move when it is in a situation >>where the move first in its movelist might be considered poor (or it is >>just failing low). This is also a non-chess element in my opinion, since >>chess is played with a time constraint, but also with a freedom to >>allocate the time as you see fit, and I bet this is the assumption of >>the programmer when he designes his search. >> >>So, it's a random element added to the game. And what are the benefits? >>Just the small conveniance to be able to report one move EXACTLY every >>2nd hour. >> >>Doesn't make sense to me. >> >>Ralf >>> >>>Uri > >Hi! > >And your suggestion is? If you have one computer and tries to play a sort of >correspondence-game. Isn't it reasonable to decide a time for each move in >example 2 or 24hours? Who should decide what is a fail low/high, maybee one >program fails low two or three times in a row and the solution is say 100h away. >This is the rules for this match and the result is nothing else then what I >believe is an interesting game and probably of higher class then an ordinary >tournament-game. > >Bertil It is possible to use more time after failing low but it should be mentioned in the decisions before the game. People can decide that the the time control is 80 hours per 40 moves when the operators can decide about the time allocation. It is also possible to decide clear rules for 80 hours/40 moves. Programs are going to use at move n(assuming they are out of book) f1(n)*reaminedtime(n) when f1(n) is a function that the users decide about before the game and reaminedtime(n) is the maximal time that the program may use for move n without losing on time. f1(n) may be 1/(40-n mod 40) if the users want to use the average time per move in normal cases. When a program fails low by at least x pawn rleative to the score in previous iteration it may try to finish the iteration or to find a score that is not clearly worse than the score in the previous iteration but without using too much time. There should be an exact definition of the meaning of too much time as a function of the number of moves. The maximal time that should be used is: f2(n,x)*reaminedtime(n) when reamainedtime(n) is the maximal time that the program can use without losing on time and f2(n,x) is decided before the match and is bigger than f1(n) for x>0. Uri
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.