Author: Sune Fischer
Date: 13:17:09 11/11/02
Go up one level in this thread
On November 11, 2002 at 15:59:40, Sune Fischer wrote: >>> >>>The math here is wrong - it should be: >>>0.6*0.9 + 0.4*0.1*0.3 = 0.54 + 0.012 = 0.0552 >> >>The math is correct >>You cannot change my calculation and decide that my math is wrong. >> >>I think that you assume that I assume that the program always use 90% of the >>time for the move that it expects. >> >>I did not say it. >> >>There are 2 kind of moves: >> >>Moves type A:Moves that the program has the move that is going to be played in >>the pv. >>Moves type B:Moves that the program does not have the move in the pv. Oh, I get it now, it's the utilization of the CPU of course. In that case you need another percentage, like this: >Moves type A:Moves that the program has the move that is going to be played in >the pv and are correctly pridicted x percent of the time. >Moves type B:Moves that the program does not have the move in the pv. (I don't know) If we assume x is 50 like Bob's example, the first part of you equation would be A% times 50% times 90% CPU, looks like that will be hard pressed to compete against Bob's 50% times 100% CPU. Of course the assumption is that A=100, so you only have 10% CPU to burn on the remaining 50% of the moves. You need 50% efficiency out of those 10% to compete with Bob, and you have only moves that failed low to search, I'd almost say that is impossible. -S. >>I assume that moves type A are 60% of the moves. >> >>I said that it is possible that the program use in average 90% of the time for >>the played move in moves type A and 30% of the time for the played move in moves >>type B. >> >>The point is that moves type A are not random moves and most of them are forced >>positionally or tactically so the program can see after a short search that one >>move is better than the other moves so it is using 90% of the time for the >>expected move. >> >>The moves type B are not forced moves and in most cases there are 2 or 3 moves >>that have the same score or almost the same score so the program can use 30% of >>it's time for every one of these moves. >> >>Uri > >I think you are both wrong :) >But I'm not sure you are trying to calculate here, shouldn't it be the expected >ponder success rate? >Looks like you are calculating 0.6*0.9+0.4*0.3=0.66>0.6, or: > frequency of type A times percentage of search time + .... > >Whatever that is, it isn't the same. > >Bob's example was that in more than 50% of the cases the second move in the PV >would be a correct guess, hence a ponder success rate of more than 50% (or >0.50). >This was only type A moves, ie we assume there is always a move to ponder. > >We could get the full success rate if we apply a ponder scheme to type B moves >also, but I think the question was only about the optimal strategy if there is a >move in the PV, otherwise it isn't so clear what to do. > >-S.
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.