Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Mobility

Author: Uri Blass

Date: 02:35:40 01/07/05

Go up one level in this thread


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



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.