Author: Uri Blass
Date: 02:39:13 01/07/05
Go up one level in this thread
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. > >Uri >Uri 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. Uri Uri
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.