Author: Vasik Rajlich
Date: 06:25:31 03/15/04
Go up one level in this thread
Fabien, your project is interesting, because I think a lot of the programmers are wondering how many of their own evaluation terms are actually useful, and how many just slow things down, introduce bugs, etc. Are there any "final" numbers regarding the strength of your engine? Also, I would be curious to see the results of a reasonably strong mature engine, with its evaluation function greatly condensed to some very simple, but still logical, piece-square tables, and some necessary material eval & passed pawn stuff. Vas On March 15, 2004 at 06:22:09, Fabien Letouzey wrote: > >Hello, > >I missed many posts during the week-end. >Sorry that I am putting the answers into a single post. >I think it's useless to answer old posts here (they get unnoticed, or?). > >Please only quote selected parts of this post if you reply, thanks! > >Fabien. > >--- > >On March 12, 2004 at 16:14:50, Uri Blass wrote: > >>On March 12, 2004 at 14:49:28, Steve Maughan wrote: >> >>>Amazing! >>> >>>I'm amazed at Fruit's score. I've downloaded it and it seems like a robust >>>engine but I note that it's quite slow and according to the author has little >>>knowedge above and beyond piece tables. Monarch is my engine. It's nowhere >>>near as strong as Fruit - I'd estimate Fruit is +200 ELO stronger than Monarch. >>>Like Fruit, Monarch also has just piece tables and I believe that Monarch is >>>probably even a little faster than Fruit. Like Fruit Monarch also has Null >>>move, check extensions and hash table (2 probes) i.e. on paper they seem to be >>>close in spec. So the question is what makes Fruit so strong? >>> >>>a) Fewer bugs - quite possible! >>>b) ETC - Monarch doesn't have this - Fruit does >>>c) No PV cut-off's in Fruit >>>d) Better piece square tables >>>e) Combination of b, c & d >>>f) ? >>> >>>Of course another explanation is that Fruit is much more sophisticated than the >>>author claims but I see no reason to think this. >>> >>>Any thoughts? >>> >>>Steve >> >>It has some boolean features. >> >>I understood that it also has some pawn structure evaluation. >> >>Uri > >a) maybe; but Fruit is untested. >b) I only expect effects in very few positions, but I think it doesn't hurt. >c) makes the search more stable, but I think it hurts overall (much slower >"next-move search" startup) >d) no >... > >Uri is right; > >1) I use a "static" pawn eval (no interaction with pieces). Only basic pawn >types (inc. passed) + a "bogus" definition of candidates (some people call those >"hidden passed pawns"?). >2) There are boolean features for sliders, they are penalysed when "behind" "own >pawns" (e.g. behind for bishops means "is there a 'own pawn' along forward >diagonals"). > >It never crossed my mind to write a piece-square-table program. >Pawn eval is one of my main goals in the long term. > >--- > >On March 12, 2004 at 18:02:56, Uri Blass wrote: > >>It may be interesting to compare Crafty with fruit's evaluation to Fruit to see >>if Fruit really has big advantage relative to Crafty in search rules or I simply >>overestimated the value of Crafty's evaluation. >> >>Uri > >I don't understand at all, of course. >1) I consider Crafty to be at least 200 elo points stronger than Fruit, making >any comparison a loss of time. >2) I don't believe a second that Fruit's search is superior to Crafty's in any >way. > >Uri, you have already mentionned ETC. >Maybe programmers can post here result of matches, same program w/ and w/o ETC. >I would be surprised if it affected match results at all, although I like to >think it can "save the day" in endgame now and then. > >--- > >On March 12, 2004 at 16:05:23, Russell Reagan wrote: > >>On March 12, 2004 at 15:01:01, Dann Corbit wrote: >> >>>>c) No PV cut-off's in Fruit >> >>I have a few questions about the 'no pv cut' idea. >> >>What is the goal of doing this? Is the intent to make the engine stronger, or is >>it only to have longer PVs in the search output? From Fabien's comments in the >>earlier thread, I thought it was only to give longer PVs, but from Steve's >>comments, I get the impression that he thinks it could be a reason for increased >>playing strength. > >Fruit was written last year, and I believed then that PV nodes were "special". >I decided to treat them a bit like the search root (except from re-using move >ordering from last iteration). >Also as a game observer, for some reason, I don't like seeing engines only >displaying 2 moves in the PV; I want to know *why* the PV was changed. Fruit >was my own program so I could at least make sure it never happened in it. >So the reason(s) had nothing to do with strength. I believe it makes the search >"more stable" whatever that may mean, but I think it costs a lot. Whether this >feature improves strength is an open question, but I think it hurts more than it >helps. >However I like the cosmetic aspect of it; SCID shows the position at the end of >the PV, and in Fruit it is always the position whose value was backed up to the >root (otherwise there is a bug). This will be very useful if I find the time to >work on the evaluation. > >"Complete PV" is going to be a UCI option in Fruit 1.0 to be released this week. > Also, just like Tord, I like using features that make my program "different" >from most other "average" amateur engines. > >--- > >On March 12, 2004 at 17:19:38, Steve Maughan wrote: > >>Russell, >> >>>...earlier thread, I thought it was only to give longer PVs, but from Steve's >>>comments, I get the impression that he thinks it could be a reason for >>>increased playing strength. >> >>I was just saying *maybe* it's a reason for additional strength. Could it >>stabalize the search and could this have a much more profound impact on the >>strength than one might initially think? >> >>Something is 'different' about Fruit if, as the author says (ands I've no reason >>the doubt), it has such a simple evaluation - Dann implied it was probably the >>search. >> >>Steve > >I am not sure if Fruit's differences matter at all, strength-wise. > >Maybe here is the place to copy a possibility mentionned by Uri: maybe Fruit >just has less bugs than the other engines in the same category. >My opinion is instead that they might be too busy with dozens of features that >reduce node count but are not so important. > >I repeat here that I don't think Fruit has a search that is any better than a >"normal" one (again, only talking about average amateur level). >Maybe its "competitors" have tried to hard (remember of Icare?). >Just a suggestion. > >--- > >On March 12, 2004 at 18:03:20, Russell Reagan wrote: > >>On March 12, 2004 at 17:19:38, Steve Maughan wrote: >> >>>>...earlier thread, I thought it was only to give longer PVs, but from Steve's >>>>comments, I get the impression that he thinks it could be a reason for >>>>increased playing strength. >> >>>I was just saying *maybe* it's a reason for additional strength. Could it >>>stabalize the search and could this have a much more profound impact on the >>>strength than one might initially think? >> >>That does make logical sense. However, good search enhancements are often >>counter-intuitive, but not always. >> >>If avoiding hash cuts at PV nodes is any strength improvement at all, then I >>wonder if it is also beneficial to avoid all pruning at PV nodes (i.e. null-move >>cutoffs, etc.). Reducing search instability and pruning blindness would be very >>good things. > >I do indeed avoid null move at PV nodes by "design" goal. >The consistency here was to treat PV nodes in the same way as the root. >Note again that I am not claiming any gain in strength with these features. > >--- > >On March 12, 2004 at 15:56:29, Steve Maughan wrote: > >>Dann, >> >>>He has a very good search. He obviously spent a lot of energy on it. >> >>OK - so this implies that Fruit is not doing just Null move (R=3) with ETC, >>Check extensions and check in first ply of Q-Search. Are there other tricks >>that Fruit is using to reduce the size of the tree or improve the branching >>factor? I did notice that Fruit seemed to be getting though the plys quite >>quickly. >> > >I am doing only what you have written. No tricks. >My move ordering is also very basic; it is not even using IID or SEE. > >If I ever have time to work on B.F., I would first focus on move ordering. > >---
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.