Author: rasjid chan
Date: 10:52:16 04/30/04
Go up one level in this thread
I will first add certain notes about MLR tuning:- If it works, it is best for factors that feature in most nodes like:- 1) piece value for each piece type 2) mobility - as it features almost at all nodes. 3) bishop pair and lone-bishop evaluation as very ofen we have at least one bishop 4) PST. etc... Uri, I remember once you posted some disappointment about Movei not yet very strong etc... and you have some interest about search vs evaluation. From the posts in this thread and some other recent posts, it seems there is still some opinion that search has far greater importance then evaluation. I have some suspect. I'm no expert but I think it's ok to add a little. We assume search() that are equal. The case where one engine on average near ply 10 searches +2/3 plys more (too much !) on average generally has a very safe margin even with a weaker eval(). We set certain preconditions :- 1) No bugs. Debug autoplay should be free from assert() errors - provided you use assert(). 2) You have a "good enough - GE" evaluation. This is the main thing. We know/assume all top programs have an eval that is more than just material so evaluation must play a part, maybe even an important part. Lets say two such equal search() program plays and one has a "good enough GE" eval and the other "not good enough NGE". NGE gets a pv and plays the move. If this pv score comes from an eval() that triggers a big item factor but not in it's eval and GE detects it in it's eval - it may be the killer. What is Good Enough Evaluation ? Maybe there are eval() factors that may be considered important or fairly important and when such factors, especially if they are common, are missing then the eval() is NGE. There is some possibility that if the eval() is still NGE, then our program cannot improve as even when a correct search idea is implemented, this NGE eval() will distort the result of any testing.This may be ONE IMPORTANT REASON why Movei has reach a certain limit. I'll like to set some tentative (HIGHLY) question and if any of your reply is "No" then your eval() is NGE. For the following assume that it is good to consider side-on-move whenever relevant as chess depends on which side is on move. 1) When one side makes a recent capture, material is off-balanced. If there is an off-setting equalizer:- Can your eval() returns within near zero ? (tough one, not even Crafty). 2) When a Queen is threaten by a smaller piece. Do you eval this? If yes, do you eval() if Queen is xside and the max piece of "side" is a rook when the weight assigned may even be near Q-R or (Q-R) / 2 etc. Yes or No. 3) when a side has a piece that can take a safe step and checks and at the same time captures a larger piece, Do you eval() this? Do you also add side-on-move considerations? 4) do you count and eval() the number of safe checks + number of piece with safe checks for each side for every eval? 5) Do you hav a very good mobility eval for at least the sliding pieces? (I dont know what is good here. MLR may best help) I have some vague idea that qsearch covers some things that eval() missed. Also a current reply below from Bob Hyatt (diminishing returns) seem to indicate eval of pin pieces may not be very important. I think it only apply to factors that take a few moves to resolved, definitely not about mobility. Please take this post with a handful of salt. Best Regards Rasjid
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.