Author: Sune Fischer
Date: 23:48:19 11/11/02
Go up one level in this thread
On November 11, 2002 at 17:39:50, Uri Blass wrote: >>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. > >1)I assumed that x is 60% in my example. So we agree, there is one move with 60% probability of being the best, and all the remaining moves cannot sum to more than 40%, for a total of 100% of course. >2)I do not understand what you say here. I don't blame you, it wasn't very elegantly put. Hopefully this time I've made myself understandable :) >I will explain again what you can practically >do in your search: > >You can start with 90% time for the expected move >and 10% for the rest of the moves with possibility to >change it based on the evaluation(if you find >during the search that the move that you expect >is a bad move you can give more time >for other moves and you can also give more time >for other moves if you find that the score >of other moves is the same as the score of the move that >you expect. Yes you can, but you then get 90 efficiency on the 60% expected move, that's 0.6*0.9+(something), this (something) must be something less than 40 times the 10% that remains, right? So 0.6*0.9+0.4*0.1=0.54+0.04=0.58 which it less than Bob's 0.6*1.0=0.6. Further more it is an upper limit that assumes you are always able to pick the correct second move, most probably you won't be 100% correct here, let's say you are only right half the time (or equivalently: that you distribute the remaining 10% CPU power over more than 1 move), that comes to: 0.6*0.9+0.4*0.1*0.5=0.56 which is even less, but also more realistic. The only move that can give you 60% return on invested CPU power is the PV move, therefore pondering that is the most effective. What to do when we _don't_ have a pv-move is a completely different question (type B moves). I guess it is also possible that one might "detect" when the PV-move is among those 40% misses, and thus effectively increase CPU returns, I think this is really what you are talking about. However I don't think I would waste any power (even 10%) on searching other moves until there is some indication the PV-move is a bad choice. >The total result may be 90% time for the >expected move when your pv includes the best move >and only average of 40% of your time for >the expected move in other cases >so you can practically get 30% of your time for >the played move that is different than the expected move. Maybe we misunderstand each other, you seem to be mixing in the type B moves in the calculation, I think that is rather confusing since we don't know the percentage of A versus B moves. -S. >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.