Author: Severi Salminen
Date: 14:47:00 02/24/01
Go up one level in this thread
>>Well I think that the most of chess programs count all visited nodes - there is >>not too much to interpret on that one. So whenever we enter a "new" node we >>increment a counter. > >Yes, but do you count make_move or do you count every time you enter search. It >makes a difference if you generate illegal moves, make them and discover you're >in check. You did do a make_move but not a new entrance in search ( or maybe you >do and jump out if you can take the king ) I still think that this is the wrong way. I think a node is a position in the game tree and if you count an illegal position a node then you are not counting right. I am incrementing in the beginnig of search() and in the beginnig of qsearch() (i call qsearch() in search() _before_ incrementing...) and this is the "right" way in my opinion. Incrementing in makemove() leads to false figures. Also an engine without a incheck function can give too high figures - I mean a case where you don't check if a move is illegal until the next ply. If you increment in makemove() you also get higher nps if you use futility pruning and on the other hand nullmove leads to opposite effect. This NPS thing is easy to figure out if you think of game tree. IMO NPS means how many nodes have you visited from which you returned some search info. And returning info about illegality is not search info but info about the rules of the game. >Lots of interpretations. But still it's impossible to compare programs. I do >things in my evaluation that can save me a few ply of search. So I have low nps >but good effective depth. Yes, that is exactly to the point. I can remove futility pruning, extended futility pruning, razoring, SEE and lots of other things and increase my NPS by 3-fold but still it plays weaker. Actually if I remove SEE and replace it with MVV/LVA the strenght difference on a slow machine with fast time controls is not very big. But on faster machine it gets emphasized. Futility pruning is very good example. Instead of calling qsearch() and incrementing a node counter you check the futility condition (stand pat cutoff) at previous ply. You lose _a lot_ in nodes (probably 30%-60%, haven't tested) but _nothing_ in strenght - even if you don't use lower futility margin than your highest positional score. >A good example of this is checking if your passed pawn is out of reach of the >opponents king ( and he has no other pieces ) It takes time but can save you 10 >ply of search easily. Yep, it's all about the right balance. >I knew a guy who was a bit ashamed of his low nps that he actually did >inc(node_counter,7) But then again, he had very original other ideas as well. >One of the best was the amateur-professional heuristic. He noticed that his >program would play nice against professionals but then somewhere thought he >could win a piece only to find out a few ply later that he had just wrecked his >position. So his heuristic was: If you play a better engine and think you can >win a piece, prune this line because it isn't good. >Worked very well, extending his losses with at least 20 moves. He threw it out >when once he played a good engine and could have won a piece. Amazing idea! If you are winnig a piece, don't take it because it can't be a good move...I have to try that! Again an old new paradigm ;-) Severi
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.