Start EndGame - A matter of fine tuning ???

[laoliveirajr]

.

Start EndGame - A matter of fine tuning ...

With the engine Capivara were launched and tested numerous versions numbered LK0.08bXX ...

Specifically the main difference between the versions LK0.08aXX and LK0.08bXX versions, is that the latter brought a pair of functions Search-Evaluate-Quiescence independent between points-of-views of the board analyzed/evaluated in the current ply/depth.

In the last few months had been tested dozens-more-dozens of builds.
For each change had to test with 30 different combinations of PeiceValues​​/PST for each side-of-power the point-of-view of the board.

With so many tests, I had forgotten the good old set PieceValue/PST the good old Capivara. In the meantime there have been many small changes that added up deserved a new version number: Capivara LK 0.09 ...

But there is still a small issue to be discussed and tested: The MaterialPieceValue to start phase EndGame.

I have two options, which one should I prefer?

In one option, Queen+1MinorPiece or 4MinorPiece or 1Rook+2MinorPiece or 2Rook start the EndGame, but 2Rook+1MinorPiece is still in MiddleGame.
In another option, increasing 25 centipawns in MaterialPieceValue limit, 2Rook+1MinorPiece also start the EndGame.

In the first option, the engine draw some games which could win.
- Capivara LK 0.09a01

In the second option, the engine loses some games which could draw.
- Capivara LK 0.09a02

What should be the best way?
When entering the EndGame?

???

[laoliveirajr]

.

The EndGame start - A matter of fine tuning ...

With the engine Capivara were launched and tested numerous versions numbered LK0.08bXX ...

Specifically the main difference between the versions LK0.08aXX and LK0.08bXX versions, is that the latter brought a pair of functions Search-Evaluate-Quiescence independent between points-of-views of the board analyzed/evaluated in the current ply/depth.

In the last few months had been tested dozens-more-dozens of builds.
For each change had to test with 30 different combinations of PeiceValues​​/PST for each side-of-power the point-of-view of the board.

With so many tests, I had forgotten the good old set PieceValue/PST the good old Capivara. In the meantime there have been many small changes that added up deserved a new version number: Capivara LK 0.09 ...

But there is still a small issue to be discussed and tested: The MaterialPieceValue to start phase EndGame.

I have two options, which one should I prefer?

In one option, Queen+1MinorPiece or 4MinorPiece or 1Rook+2MinorPiece or 2Rook start the EndGame, but 2Rook+1MinorPiece is still in MiddleGame.
In another option, increasing 25 centipawns in MaterialPieceValue limit, 2Rook+1MinorPiece also start the EndGame.

In the first option, the engine draw some games which could win.
--- Capivara LK 0.09a02

In the second option, the engine loses some games which could draw.
--- Capivara LK 0.09a01

What should be the best way?
When entering the EndGame?

???

P.S.
The engine version numbers was incorrect in the first post.

[lucasart]

But there is still a small issue to be discussed and tested: The MaterialPieceValue to start phase EndGame.

The transition between middlegame and endgame should not be discontinuous. So what you're doing is essentially bad, regardless of where you choose to put the discontinuity: this is what engines did in the pre-Fruit era (a.k.a. paleolithic)
The linear transition between opening and endgame was one of the breakthroughs of Fruit (2004). I suppose everyone does something like that nowadays.

In the first option, the engine draw some games which could win.
--- Capivara LK 0.09a02

In the second option, the engine loses some games which could draw.
--- Capivara LK 0.09a01

Never draw conclusions from looking at games, however tempting it may be. Only look at statistics, error bars etc.

[michiguel]

But there is still a small issue to be discussed and tested: The MaterialPieceValue to start phase EndGame.

The transition between middlegame and endgame should not be discontinuous. So what you're doing is essentially bad, regardless of where you choose to put the discontinuity: this is what engines did in the pre-Fruit era (a.k.a. paleolithic)
The linear transition between opening and endgame was one of the breakthroughs of Fruit (2004).

Phalanx was doing it long before that.

Miguel

I suppose everyone does something like that nowadays.

In the first option, the engine draw some games which could win.
--- Capivara LK 0.09a02

In the second option, the engine loses some games which could draw.
--- Capivara LK 0.09a01

Never draw conclusions from looking at games, however tempting it may be. Only look at statistics, error bars etc.

[laoliveirajr]

In the first option, the engine draw some games which could win.
--- Capivara LK 0.09a02

In the second option, the engine loses some games which could draw.
--- Capivara LK 0.09a01

Never draw conclusions from looking at games, however tempting it may be. Only look at statistics, error bars etc.

That was because I just looked at the statistics ... :
[64 games against the same reference engine (reference engine to test engines LK 008 series)]

Code: Select all

Rating.dat
==========
    Program                       Elo    +   -   Games   Score   Av.Op.  Draws
1 Capivara LK 0.09a01 64-bit   :   22   81  80    64    56.2 %    -22   15.6 %
1 Capivara LK 0.09a02 64-bit   :   22   67  66    64    56.2 %    -22   40.6 %

Programs.dat
============
1 Capivara LK 0.09a01 64-bit:   22   64 (+ 31,= 10,- 23), 56.2 %
1 Capivara LK 0.09a02 64-bit:   22   64 (+ 23,= 26,- 15), 56.2 %

[laoliveirajr]

But there is still a small issue to be discussed and tested: The MaterialPieceValue to start phase EndGame.

The transition between middlegame and endgame should not be discontinuous. So what you're doing is essentially bad, regardless of where you choose to put the discontinuity: this is what engines did in the pre-Fruit era (a.k.a. paleolithic)
The linear transition between opening and endgame was one of the breakthroughs of Fruit (2004). I suppose everyone does something like that nowadays.

From the beginning, there was only CapivaraLK008b04/02a/03a/04a to the same PST LK007 series, with only the KingEndGame (Like the TSCP).

The Capivara LK008b05/06/07/08/09 were discarded, because I found a big bug, they were also implementing EndGame, among other improvements ...

The Capivara LK008b10/b11/b12 had only beta versions, where many were tested PST, with endgames, and some versions also had EndGameBonus for PieceValues ​​...

Now, with Capivara LK009 I resumed my old CapivaraPST with recent BonusPST (yes! for the Capivara, a PST just like the TSCP-PST works better than the "common PST" as is the "Rybka PST" or "Fruit PST" among other tested PST !!!)

The PST as the TSCP-PST is part of Evaluate00, called by Search00, considering the diagram below.
The Evaluate22 making a counter point, contains elements common engines, and elements not allowed in Evaluate00
The same occurs with SeachXX and QuiescenceXX

How Capivara LK 0.08b0x works...

How Capivara LK 0.08b0x works...

Already occurred to me the idea of ​​dividing the game in several stages, in which the engine would several PSTables, several PieceValues​​, including progressive PawsValuesBonus, but this can only occur after very well defined "what is a good EndGame status".

And the question returned:
What should be the best way?
When entering the EndGame? or...
What is a good EndGame status???

.

[Evert]

64 games is not remotely enough to test anything...

[laoliveirajr]

64 games is not remotely enough to test anything...

My engines are published immediately so after compilation.
The tests start thereafter.
The computer is still running ...
.
.
.

[wgarvin]

64 games is not remotely enough to test anything...

My engines are published immediately so after compilation.
The tests start thereafter.
The computer is still running ...

What he meant is that statistics from 64 games are meaningless -- the error bar is huge. You probably need to run thousands of games to measure whether changes are good or not.

[laoliveirajr]

64 games is not remotely enough to test anything...

My engines are published immediately so after compilation.
The tests start thereafter.
The computer is still running ...

What he meant is that statistics from 64 games are meaningless -- the error bar is huge. You probably need to run thousands of games to measure whether changes are good or not.

Yes, I understand perfectly ...

but ...
After my last post I've compiled 5 new versions, which are running on gauntlet ...

The ideas buzzing in my head quickly ...
(I) implement the changes ...
that saw new releases ...
and more releases ...


P.S. (edited after post)
My relative amnesia is matched with a high productivity of ideas ...
arising from a mental storm ...

I have only one computer ...
I would need several machines to efficiently test all versions which I compile.