Fruit and derivatives list !

[RoySawyer]

To Rowen,

Right after I made the post I realised that the < Max Nps# > numbers were ambiguous
and I updated the engine parameters to explain them a bit more.

If you download the engine again the engine parameter list now shows
the number of pieces that they are used for.

The first thing to say is that if you have engaged the UCI_LimitStrength option
then they do not apply.

The reason I left the original code in is so that you have a choice of both methods.

If you wanted to weaken the engine via the nodes per second option
them the numbers apply to the current phase of the game as governed by
the number of pieces on the board.

Here is a fragment of the code that shows this process -

//--------------------------------------------------------------------------//

// Ryan Benitez code

phase = board_phase(SearchInput->board);

if (phase == 1)
max_nps = option_get_int("Max NPS1 (pieces >= 26)");

else if (phase == 2)
max_nps = option_get_int("Max NPS2 (pieces < 26)");

else if (phase == 3)
max_nps = option_get_int("Max NPS3 (pieces < 21)");

else if (phase == 4)
max_nps = option_get_int("Max NPS4 (pieces < 12)");

else if (phase == 5)
max_nps = option_get_int("Max NPS5 (pieces < 8)");

if (max_nps == 999999)
max_nps = 0;


// Roy Sawyer code

// this is followed by my limit strength code - somewhat simplified

// check whether UCI_LimitStrength is set in engine parameters

SearchInput->uci_limit_strength = option_get_bool("UCI_LimitStrength");

if (SearchInput->uci_limit_strength) // limit strength is set
{
// Code follows that sets < max_nps > from the < UCI_Elo > rating
// which over-rides the earlier < Max Nps# > settings that were read in

// get the elo rating
uci_elo = option_get_int("UCI_Elo");

// get the NPS_Elo adjustment value
nps_elo_adj = option_get_int("Nps_Elo adjustment");

// calculate nodes per second based on elo rating
// from the algorithm of Ferdinand Mosca
// with an added adjustment value to fine tune the conversion

// the earlier < max_nps > from number of pieces is now over-written

max_nps = (int)(pow(2.718, ((uci_elo + nps_elo_adj) / 297.12)));
}

//-----------------------------------------------------------------------//

The full code for this is in the Search() function in the file Search.cpp

The < max_nps > value is then used to govern the idle time loop
in the function search_update_current() in the file search.cpp
which in contained the < Build.7z > file in the download.

It would be possible to adjust the < max_nps > value that was calculated
for UCI_LimitStrength to account for the phase of the game
as was done by Ryan Benitez in the original code.

I suppose his idea is that by setting < Max Nps5 > lower than < Max Nps1 >,
for example, the engine would not search too deeply in the endgame.
Although human players also see deeper in the endgame.

Hope that explains the process.


Roy Sawyer

[Elorejano]

Hi! are there a place to download this ooldies?
Im only interested in winboard engines
Thanks in advance

[RoySawyer]

To Toga_II users,

I found that the < UCI_LimitStrength > option in the Toga_II
limit strength engine works much better when used in conjunction
with the < Variety > option combined with the < Allowed deficit >

However, when I was working on another limit strength engine,
I realized that I had incorrectly set the upper limit on the
< Allowed deficit > I had set it to 100 (a pawn) instead
of my intended figure of 1000 (a queen).

Set at 100 it will not even blunder a pawn, whereas at 1000
it is possible that it will blunder a queen.
So, it you set at an Elo rating of 900, you might want the engine
to sometimes blunder a rook, so the upper limit of < Allowed deficit >
should be set to 600
To occasionally blunder a knight or bishop, it should be set to 350
for a pawn it should be about 125

The reason I over-looked this was because I mostly tested the engine
on the Nimzo_3d Chess GUI where there is not boundary checking on
all the engine parameters.
On other GUIs where the number parameters are entered via spin controls,
the parameter boundaries are enforced.

I have corrected this mistake and you can download the new version
of the engine from the same links as before.

https://www.mediafire.com/file/llameiki ... ls.7z/file

https://drive.proton.me/urls/D5WZ44PT7W#PSCsJ6Z0fr6I

My apologies for any inconvenience caused.


Roy Sawyer

[Rowen]

To Toga_II users,

I found that the < UCI_LimitStrength > option in the Toga_II
limit strength engine works much better when used in conjunction
with the < Variety > option combined with the < Allowed deficit >

However, when I was working on another limit strength engine,
I realized that I had incorrectly set the upper limit on the
< Allowed deficit > I had set it to 100 (a pawn) instead
of my intended figure of 1000 (a queen).

Set at 100 it will not even blunder a pawn, whereas at 1000
it is possible that it will blunder a queen.
So, it you set at an Elo rating of 900, you might want the engine
to sometimes blunder a rook, so the upper limit of < Allowed deficit >
should be set to 600
To occasionally blunder a knight or bishop, it should be set to 350
for a pawn it should be about 125

The reason I over-looked this was because I mostly tested the engine
on the Nimzo_3d Chess GUI where there is not boundary checking on
all the engine parameters.
On other GUIs where the number parameters are entered via spin controls,
the parameter boundaries are enforced.

I have corrected this mistake and you can download the new version
of the engine from the same links as before.

https://www.mediafire.com/file/llameiki ... ls.7z/file

https://drive.proton.me/urls/D5WZ44PT7W#PSCsJ6Z0fr6I

My apologies for any inconvenience caused.


Roy Sawyer

Thank you for sharing. So would I be right in thinking that variety relates to likelihood of blundering (and allowed deficit would be severity of blunder)? so basically Elo reduction slows down the engine and variety and deficit introduce/ simulate blunders?

And also could you explain Moves to play? Thanks for your time.

[RoySawyer]

To Rowen

It is pretty much as you surmised but a little more complex.

< Variety > is the number of moves that the engine will consider when selecting its move.
< Allowed deficit > is how much worse a move can be than the best move available
and still be considered for selection.

For example, say that < Variety > is set to eight, when the engine is searching
it will get detailed information on eight lines using the < MultiPV > searching option
which is automatically set to match the number selected for < Variety >

If we take this line of the Cochrane gambit from the Petroff defence
with the engine playing white

After

1. e4 e5
2. Nf3 Nf6
3. Nxe5 d6
4. Nxf7 Kxf7

So with < Variety > set to eight,
say that the < Allowed deficit > is set to 200 centi-pawns.

Then the engine will have information on eight moves after the search -

5. Nc3 -0.77 minus 77 centi-pawns
5. d4 -1.54
5. a3 -1.91
5. d3 -1.96
5. b3 -1.96
5. a4 -1.97
5. c3 -2.03
5. h3 -2.14 minus 214 centi-pawns

So the last two are ruled out because they are greater than
the allowed deficit and the engine will pick a move at random
from one of the first six.

When I was writing the code for < Variety > my only intention
for it was to vary the play.
It was only afterwards that I realised that it could be used
in conjunction with < UCI_LimitStrength > to more finely tune
the playing strength.

However, < Variety > can be used just to vary the play,
if the < Allowed deficit > is set quite low, say 30 centi-pawns.

It is quite a difficult task to devise and implement an algorithm
that will produce an engine playing strength that accurately corresponds
to a given ELO rating, so you will probably have to experiment
quite a bit with the three adjustment parameters
< Nps_Elo adjustment > < Variety > and < Allowed deficit >
to get something that you are satisfied with.
Raising the < Nps_Elo adjustemnt > value makes the engine stronger
lowering makes it weaker.

As for < Moves to go >, this is the number of moves that the
engine is required to play in whatever time it has remaining.
So if it has 2 minutes, 40 seconds left (160 seconds)
and moves to go is set to 40 for that time period,
it will calculate the time available for its next move as
160 / 40 = 4 seconds and spend roughly that amount of time
on its next move. So the engine will play progressively faster
as its time ticks away.
I have set different numbers for various time periods to
even out the time usage a bit. Although I find it best to
set a higher number for the last minute, so that the engine
does not lose on time.
If you find the engine has a lot of time left at the end
of a game then the < Moves to go > numbers can be lowered a bit
and if it is losing on time, then raise them a bit.
Although making it play faster is another way of weakening the engine.

Hope this helps.

Roy Sawyer

[RoySawyer]

To Rowen,

It is often the way, right after I made the post,
I realised the mistake I had made.

In the case given, all eight moves would be considered
because even the last two are not 200 centi-pawns
worse than the first move.

I thought that I had better correct this mistake
before someone else did.

Roy Sawyer