new version of movei is going to be released soon

[Uri Blass]

I sent Leo a new version of movei that is going to be released and users will
be able to change many parameters but not everything and a lot of parameters are still constants.

There is no difference from the version that was used in WBEC except some code
that is not relevant for playing strength.

One thing is that I fixed a bug in learning but the bug had no negative effect in Leo's game and 00_8_294 with the bug did not learn but still did not repeat the same loss.

Other changes are cosmetic changes and I did not work in the last days about improving the playing strength.

Uri

[Reinhard Scharnagl]

What is about Chess960/FRC?

Regards, Reinhard.

[Uri Blass]

Hi Reinhard,I do not see the connection of FRC to my post.

I only release a new version of my engine that is only a chess playing engine.

Note only about calculation of perft that I did not release the fastest version but I decided that it is not very important to release 2 different versions when one is only for perft when the second version is for games.

Uri

[Uri Blass]

you can download new movei in the wbec pages now.

Uri

[Reinhard Scharnagl]

Hi Uri,

I do not see the connection of FRC to my post.

sorry for that: each new version always is a new chance to also support FRC.

Note only about calculation of perft that I did not release the fastest version but I decided that it is not very important to release 2 different versions when one is only for perft when the second version is for games.

Now it's me who cannot see a conection to my short posting. So please help me to understand your intention!

Reinhard.

[Peter Eizenhammer]

you can download new movei in the wbec pages now.

Uri

That is great news, Uri! Thank you very much for the new version!

I just had a look at the personality feature, because i like this kind of stuff.
Would you be so kind and explain the parameters a little bit,
for example minimal and maximum values, so that one can guess what might make sense?

Peter

[Uri Blass]

I will give more explanations later.

I admit that not everything is clear based on the name and even I do not remember everything but here are some explanation for the first parameters:

loghash means hash size and 22 is 2^22 hash entries that are 64 mbytes

resign_value is the value of resigning in sentipawns (-1000 means resign when the evaluation is -10 or smaller(there is also some minimal number of nodes to resign so it will not resign based on short searches)

logfile 0 means no logfile

Replacealways means replace always in the hash

The idea was to save time by not clearing the hash between moves but practically I still did not implement not clearing the hash always between moves in this version (movei in this version clears the hash after searching enough nodes) and I forgot about implementing never clear hash option so I think that it does not make sense to change it to 1(in that case movei may use replace always but also clear the hash sometimes and it is clear that if it replace always it is better for it also not to clear the hash).

win_learning means the importance of wins to learning to repeat win and lose_learning means the importance of losses to learning to avoid losses.

the default values means that the learning value of a move is increased by 1 after a win and reduced by 1 after a loss.

There is learning value for every ply in the first plies of the games.

I think that the square tables are intuitive and it gives the piece square table that movei is using for the black pieces from a1-h1 to a8-h8.

king safety table tell you the score that movei is giving for king safety based on the king safety table value that is basically calculated based on control of the opponent near the king and the question if there are missing pawns near the king.

King safety evaluation should be improved and today it does not include
control of squares that are in all the squares and only pressure against squares h2 g2 f2 are considered for white king at g1(no f1 h1) and f1 g1 h1 are also not considered for king at g2.

king relative to pawn table gives score for the king based on pawns
It was thanks to idea of Tord.

The idea was to give a bonus for king that blocks the passed pawns.

Movei is using the following formula when values for kingpawnbonus are given in the table.

kingpawnbonus is 13*8 array
int kingpawnbonus[13][8];

every 8 numbers means different difference in ranks from the passed pawn(from easy to block the pawn so movei does not care about the exact file of the king to hard to block the pawn so movei does not care about the exact distance).

Movei has different function to punish king that cannot block the pawn based on the rank of the king and it is the reason that it does not care in this table for the question if the king is in smaller rank than the passed pawn or in higher rank than the passed pawn.

The king needs to block the pawn but when the pawn needs 5 or 6 small moves to get to the rank of the king movei does not care about the distance in file so distance 0-7 get the same 0 score

when it is 4 movei start to care when the distance in file is big and give bonus of 0.05 pawns for distance of 7 or 6 files or 0.03 pawns when the distance is 5 files or 0.01 pawns for distance of 4 files and continue in that way based on the table if I understand it correctly.

Here is the relevant code from movei in the function to evaluate white pawns and there is a similiar function to evaluate black pawns.


score+=kingpawnbonus[rank0(square)-rank0(kingsquare[LIGHT])+6][FileDistance(square,kingsquare[LIGHT])]
-kingpawnbonus[rank0(square)-rank0(kingsquare[DARK])+6][FileDistance(square,kingsquare[DARK])];


paneltyfiles punish king based on the distance of it in files from the pawns.

progress give some bonus for the initiative and is part of movei evaluation that is not dependent only on the leaf position(I do not want to reveal too much about it).
It may be interesting to test increasing this value but movei may also be more unstable if you do it (basically sequence of increasing positive values is logical sequence for progress).

Maybe it is a good idea to increase 20 to a bigger number but I do not know.

Uri

[Uri Blass]

Hi Uri,

I do not see the connection of FRC to my post.

sorry for that: each new version always is a new chance to also support FRC.

Note only about calculation of perft that I did not release the fastest version but I decided that it is not very important to release 2 different versions when one is only for perft when the second version is for games.

Now it's me who cannot see a conection to my short posting. So please help me to understand your intention!

Reinhard.

Hi reinhard,

The only connection is that you talked about perft in the past and after your post I thought that maybe people may be disappointed about the speed of movei in perft so I wanted to explain the reason that it is almost twice slower than the speed that I mentioned for movei in perft mode in the past (the reason is that the version that I released is not using perft mode).

I do not consider speed of perft that I release as very important for other programmers as long as it is not very slow and I consider it only as a debugging tool to help other programmers.

Uri

[Reinhard Scharnagl]

Hi Uri,

I do not consider speed of perft that I release as very important for other programmers as long as it is not very slow and I consider it only as a debugging tool to help other programmers

I agree at most, but a good perft result also is a good indicator for having a good selected data structure. In Smirf the speed of move generating is this moment really irrelevant because of me evaluation function being totally slow (it has been an ad hoc implementation for the Gothic Chess Challenge 2004). May be that when Smirf also will be a mating engine (but not really specialized) that the speed of move generation might be of higher importance. But first I have to speed up my positional evaluation.

Reinhard.

[Peter Eizenhammer]

I will give more explanations later.

I admit that not everything is clear based on the name and even I do not remember everything but here are some explanation for the first parameters:

loghash means

Uri

Hi Uri,

thank you again for your answer.
There is a lot of material to play with, so one can have some fun
or even try to increase the strength.

Peter

[Tord Romstad]

king relative to pawn table gives score for the king based on pawns
It was thanks to idea of Tord.

The idea was to give a bonus for king that blocks the passed pawns.

My implementation of this idea can be seen in the source code for Glaurung 0.1.5, which was made public earlier today. I use the table not only for passed pawns, but also for all other pawns. The bonus is four times bigger for passed pawns than for non-passed pawns.

Those of you who want to have a look at the code, go to evaluate.c and look at the KingActivityBonus stuff. It is probably not very hard to improve upon my code, but I think it works remarkably well considering its simplicity.

Tord

[Uri Blass]

I will continue to explain about parameters of movei

Movei "believes" that it does not know to evaluate correctly big positional advantage and is too pasimistic about it so the idea behind bigpositional is to give bonus for positional advantage that is more than bigpositional.

The default personaloity give bonus for positional advantage that is more than 0.7 pawns based on the difference between the positional advantage and 0.7 pawns.

bigadvantage is another bonus that is given when the side to move is clearly worse.

The idea is that if some side has big positional advantage inspite of having a rook down then you may increase the evaluation of the positional advantage even more and bigadvantage 200 means that you increase the evaluation only when the side with the positional advantage is at least 2 pawns down even after considering the previous bonus.

big advantage is relevant only in cases that one side has a clear positional advantage of at least bigpositional and it is not calculated when the advantage is smaller.

old mobility table is the table that is used for mobility.
I plan to change it but I still did not do it.

open file number is bonus for rook in open file(no pawns of the opponent).

rook behind passed pawn is bonus for a rook that is behind passed pawn.

Note also that the table that I mentioned that was based on Tord's idea is only relevant in the endgame and it is possible that there is another table that is only relevant at the endgame that I forgot to mention but usually tables are relevant for all stages of the game unless I say differently in the name of the table.

knightoutpost is bonus for outposts from a8 to h1.

prefer pawn in endgame is bonus for having pawns n the endgame when it is also a panelty for having pawns in the opening.

capture bonuses are bonuses for the ability to capture(the first number is bonus for 0 capture,second nmber bons for 1 possible capture and it continues in that way).
the simple bonus capture is always applied based on the number of captures when the second bonus(bonus2) is used only when there is a positional advantage.

weak pawn opening1 is panelty for pawn that is under attack.
weak pawn opening 2 is panelty for undefended pawn under attack.

endgame is the same in the endgame.

furility prune is pruning based on remaining depth and evaluation.
reducing the values means that movei prune more and it is only logical to
have increasing sequence.

limit history depth 101 allow history based pruning only in cases when the remaining depth is smaller than 101 and practically allows it always.

You can change it for example to limit history depth 4 and allow it only in the last 4 plies if you like it or the same idea(I did not test it).

pruning_moves 25 means practically no additional pruning that I defined but did not test.

If you like you can reduce it to pruning_moves 8 or pruning_moves 7but I am not sure if it will play better(reducing it to pruning_moves 9 almost did not change the results and maybe it is too small change).

Uri