the UCI protocol is stateless, I don't think that xboard is stateless too, but this doesn't mean that the engine sould be stateless.
lot of engine I know and Vajolet too are more or less stateless, meaning that the remember the state since the have transposition table but each time they receive a new position they restart searching from scratch.
I'm considering to add some new feature to Vajolet:
- a game manager that will follow a game and create the state that UCI doesn't have.
- remember all the final PV calculated at each search
- try to use info of the previous search to have some gain for example if the other player played the pondered game we can start the new search dfrom the last PV, aspiration windows and depth-2 for example.
has this already tried in the past with good results? all the moder engine I know of treat that problem in a statelss way.
elcabesa wrote:the UCI protocol is stateless, I don't think that xboard is stateless too, but this doesn't mean that the engine sould be stateless.
lot of engine I know and Vajolet too are more or less stateless, meaning that the remember the state since the have transposition table but each time they receive a new position they restart searching from scratch.
I'm considering to add some new feature to Vajolet:
- a game manager that will follow a game and create the state that UCI doesn't have.
- remember all the final PV calculated at each search
- try to use info of the previous search to have some gain for example if the other player played the pondered game we can start the new search dfrom the last PV, aspiration windows and depth-2 for example.
has this already tried in the past with good results? all the moder engine I know of treat that problem in a statelss way.
Crafty has never been stateless. You need a game history to correctly handle repetitions. And you do NOT want the GUI to ship the entire game to the engine before each new search...
Chess is not stateless, I see no reason for the engine to be stateless.
I used stateless in a wrong way.
no engine is stateless, but up to now all the UCI engine I know of, react to a GO command doing a new search starting at depth 1, not using a previous Pv and not using the previous aspiration window. All they use of previous search are hash, killers and so on. but they don't use the real result of a previous search.
this is what i meant with stateless.
do you know if those additional info have ever been used by any engine?
You used it correctly. The UCI protocol is stateless as far as "game state" is concerned. (The engine is supposed to remember option settings such as hash table size and number of threads, obviously.)
elcabesa wrote:I used stateless in a wrong way.
no engine is stateless, but up to now all the UCI engine I know of, react to a GO command doing a new search starting at depth 1, not using a previous Pv and not using the previous aspiration window. All they use of previous search are hash, killers and so on. but they don't use the real result of a previous search.
this is what i meant with stateless.
do you know if those additional info have ever been used by any engine?
Isn't that what the ponder stuff is all about? If ponder is enabled your engine is allowed to search during opponent time and when your next turn begins you may simply continue from wherever you are in that process - you don't have to start from ply 1 - depending on what your opponent played of course.
In simpler terms that means after your engine makes a move it can start searching immediately so that when it's next turn begins it's already done several plies of search.
syzygy wrote:The UCI protocol is stateless as far as "game state" is concerned.
Yes, and I think this is a good reason to use the xboard protocol instead. Chess itself is clearly not stateless; seems like madness to me to have a protocol send the game history each and every time.
syzygy wrote:The UCI protocol is stateless as far as "game state" is concerned.
Yes, and I think this is a good reason to use the xboard protocol instead. Chess itself is clearly not stateless; seems like madness to me to have a protocol send the game history each and every time.
Maybe, but I see no reason to bring that up in this thread, even though you are the second one to do it.
elcabesa wrote:I used stateless in a wrong way.
no engine is stateless, but up to now all the UCI engine I know of, react to a GO command doing a new search starting at depth 1, not using a previous Pv and not using the previous aspiration window. All they use of previous search are hash, killers and so on. but they don't use the real result of a previous search.
this is what i meant with stateless.
do you know if those additional info have ever been used by any engine?
I always use the PV from the previous search. I take the second move and ponder that. I take the remainder of this PV and stuff it into the hash table to be sure those moves are searched first. I also use the previous value to set the aspiration window for this new search.
elcabesa wrote:the UCI protocol is stateless, I don't think that xboard is stateless too, but this doesn't mean that the engine sould be stateless.
lot of engine I know and Vajolet too are more or less stateless, meaning that the remember the state since the have transposition table but each time they receive a new position they restart searching from scratch.
I'm considering to add some new feature to Vajolet:
- a game manager that will follow a game and create the state that UCI doesn't have.
- remember all the final PV calculated at each search
- try to use info of the previous search to have some gain for example if the other player played the pondered game we can start the new search dfrom the last PV, aspiration windows and depth-2 for example.
I thought most people did that when they receive a "ponder hit": switch to normal thinking mode but continue to search. I don't think there is another situation where it makes sense to store iteration depth or aspiration bounds during game play.
Analysis might be another matter, but I don't think you get any input in UCI unless you're supposed to end the search anyway...
Normally the previous PV would already be present in the hash. It would not occur often that you wanted to search the same position again. When excluding moves from analysis this could sometimes happen.
This reminds me of something. When analyzing mini-shogi opening lines, it occurred very often that the score kept dropping with depth to an unacceptably low value. A lot of time was then wasted by figuring out exactly how bad the line was. Especially when the score of the PV drops a lot iterations start to take a lot of time, as all previous refutations of the other moves are not good enough anymore.
Wouldn't it be useful to allow the user to control aspiration in some standard way? E.g. when analyzing for the purpose of building a book I could then use a window { -50, 50}.
for example if the other player played the pondered game we can start the new search dfrom the last PV, aspiration windows and depth-2 for example.
