Author: Dann Corbit
Date: 10:24:47 01/07/05
Go up one level in this thread
On January 07, 2005 at 05:39:13, Uri Blass wrote: >On January 07, 2005 at 05:35:40, Uri Blass wrote: > >>On January 06, 2005 at 19:53:58, Dann Corbit wrote: >> >>>On January 06, 2005 at 19:15:58, Pallav Nawani wrote: >>> >>>>On January 06, 2005 at 18:18:40, David B Weller wrote: >>>> >>>>>Hi Geoff, >>>>> >>>>>The fact that you stumble over my code is probably a credit to your >>>>>intellegence, and if I tried to explain: attack_mask[][], I would embarass >>>>>myself. >>>>> >>>>>In fact, while thinking over how to best answer your question, I too became >>>>>somewhat puzzled as to how what I did, actually improves GES performance. It >>>>>really is inacurate. >>>>> >>>>>The part I added is at the end of control.cpp and 1 line in evaluate.cpp : >>>>> >>>>>s += count_ctrl() * 3; >>>>> >>>>> the '3' is pulled from memory - I think Prof Hyatt used it for Bishop mobility, >>>>>but since what I am counting isnt the same, it is probably way off. WAY off. >>>>> >>>>>The basic idea of count_ctrl() is to detirmine who 'owns' each of the 64 >>>>>squares. But it is very simple and naive. It makes assumptions which are >>>>>probably true more often than not, but still wrong much of the time. eg., if >>>>>white has a pawn attacking a square, but black doesnt have a pawn attacking that >>>>>square - white owns the square. regardless of what else is attacking it. If both >>>>>have pawns attacking [or, niether do] then the same idea is applied for knights. >>>>>Then Bishops, then Rooks, then Queens. >>>> >>>>So what you are evaluating is board control. I had no idea it was that useful. >>>>Maybe I will try implementing that (after I have implemented attack tables, that >>>>is). >>> >>>A bitboard program will have a stupendous advantage here [considering again >>>Fabian's code]. >>> >>>If you look at the eval function (where he calculates mobility) with a bitboard >>>program you can precompute EVERYTHING and every single nested loop goes away. >>> >>>By a stupendous margin, all of his program's time is bottled up by eval(). >>> >>>If Fabian's program were converted to bitboard, it could run 5x faster. How's >>>that for a scary thought? >> >>Does Fruit use more than 80% of it's time for mobility evaluation. >>If it is not the case then I do not see where the 5x faster comes from. >> >>Even if it can calculate fruit's mobility evaluation 5 times faster it does not >>mean that the program will be 5 times faster. Maybe not. It's a guess. >I can also add that the question is also if fabian will not have slower move >generator thanks to bitboards or he will be slower in other things. > >Fruit seems to be better than Crafty so it probably does something better. I am guessing that search is better, since branching factor is about 2. I think also that his evaluation is different than that of many others so that it sees opportunities that others miss. It happens the other way around too.
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.