laoliveirajr wrote:lucasart wrote:laoliveirajr wrote:
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".
...
...
...
.
.
The differences between a01a, a02a, a01b and a02b are relatively significant for me, in the conceptual point of view, had only a small difference in the results.
Yesterday I compiled 4 more versions of the Capivara LK 0.09, still unpublished: b01a, b02a, b01b and b02b.
The Capivara has two different search functions, one calculates the positions of the point of view of the Capivara, another calculates the point of view of the opponent.
I made a small change, this time removing the pruning of the function that computes the opponent's side, so the engine will prune considering only the values of Capivara.
The next change I intend to do, will be the Capivara with concurrent processing.
The splits will be made by the function that computes the opponent's side, so a function throws the threads, and the other will do the pruning.
Wait for Deep Capivara !!!
.