Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Fruit mobility question

Author: Joachim Rang

Date: 05:22:37 06/20/04

Go up one level in this thread


On June 20, 2004 at 07:05:30, Uri Blass wrote:

>On June 20, 2004 at 05:14:26, Joachim Rang wrote:
>
>>On June 20, 2004 at 00:12:22, Uri Blass wrote:
>>
>>>Is it correct that fruit evaluates mobility as the same for all directions?
>>>
>>>If I understand Fruit1.5's code correctly I do not see difference between
>>>mobility of rook in files and in ranks.
>>>
>>>The mobility score for rook seems to be the number of square that it can goto
>>>minus 7.
>>>
>>>Uri
>>
>>That is how Fabien explained it to me, so I think you are correct. One
>>specialtity is that Fruit counts all squares where the piece can go plus the
>>enemy pieces which are attacked. It is actually possible to give these two
>>concepts different weights but so far it does not seem to increase the strength.
>>
>>regards Joachim
>
>This is similiar to the way public movei already calculates mobility by the
>number of the legal moves and it has no concept of open files(mobility score for
>fruit can also be calculated based on the number of the legal moves of pieces
>when the only difference is that you need to know the number of moves of every
>piece).
>

right, Fabien wanted more flexibility, to give different values for square
control and attacking pieces, but how it is tuned right now, it is like counting
legal moves.

>I thought that I may need to change it and to define mobility forward and
>mobility backward and I saw few cases when public movei suffered from the fact
>that it did not evaluate open files.
>
>Latest movei give static bonus for open files for rooks and the same panelty for
>closed file when open files are defined the same way as they are defined in
>fruit1.0 based on Fabian's post but I am also not sure if it increase the
>strength(it beated previous version in the nunn match but scored similiar to
>movei00_8_198 in Heinz tournament).
>
>There are also some other changes when I am not sure that they increase the
>strength.
>
>I wonder if fruit1.5 evaluates open files directly seperate from mobility.
>I did not find it in the evaluation but maybe I did not look well enough.
>

The boolean mobility expressions, like bishop on closed diagonals, rook on
closed file and queen on closed files and diagonals where removed once mobility
was tuned, because it seemed that mobility does a better job.

If Fabien has nothing hidden from me, Fruit does not evaluates open files
directly seperate from mobility. There are still some (piece placement)
expressions beside pst and mobility but they are constant bonus not counting the
dynamic features of a position.

>Another question is if it evaluates knight outposts.
>

No. The PSTs are constructed in a way, that advancing knights is encouraged but
there is no evaluation whether an advanced knight is an outpost or not.

>One suggestion that may help fruit is to have some mobility table with the idea
>that very negative mobility is worse than what is suggested by the mobility
>score.
>

Can you explain what do you mean by that? Perhaps you can give an example.

>I do it in movei.
>
>I do not consider it as something that is hard to find by yourself because
>it is similiar to the idea that king safety is not something linear but maybe
>other people do not use it.
>Maybe it is one of the reasons that movei is considered by some testers to have
>good mobility evaluation.
>
>My solution to the problem of endgame(very bad mobility may be not so bad is
>simply to divide the score by 2 or 4 based on the number of pieces but I think
>that the substraction idea in fruit may be better).
>

What substraction idea? Knight and Bishop mobility is weighted the same in
opening and endgame but rook and queen mobility is weighted higher in the
endgame.


>Uri


I want to make a general comment on your program: On what do you occasionally
write here and in the winboardforum it seems that you have quite sophistated
evaluation terms, much more detailed and sophisticated than Fruit. I think
before trying to make more refinements and add more special cases to your eval
you should test which features are really relevant and which features contribute
how much to the current strength of Fruit. The way you describe your eval terms
they seem well designed to cover many positions but I think some of them may
sound good and intuitive but in fact hurt playing strength.

regards Joachim



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.