ArnoHu wrote:

S_P_A_R_T wrote:

ArnoHu wrote:

I think the 2nd fastest win of GoK (Medium) on Scratch 3 against Bonsai Blue, in 12 moves. GoK saw the mate-in-3 in 0.1 seconds: https://lichess.org/ZbCw8a8b#24

Wait… If that was the 2nd fastest win, how fast was the #1?

I think there was one, but most likely I won't be able to find it any more… maybe I am also wrong.

S_P_A_R_T wrote:

Here's a really strange WD v7.02 self play test.

This was to mainly ensure that the new table-based move gen for the pawns worked (along with some other new stuff), but this game it just terrible!

The queen get's trapped twice (and neither time does the other side realise this) and after this, the rook vs rook ending was just terrible! I stopped this game short even though black was winning because it didn't look like progress was going to occur, and even if a decisive result happened, it wouldn't really be that “important”.

https://lichess.org/jN4nYBid#107

S_P_A_R_T wrote:

White Dove v7.03 has been released!

White Dove v7.03 is slightly faster than v7.02 as I've sped up the pawn & knight move gen with pre-made tables. I've also improved the evaluation during late endgames!

Overall, this should make WD a bit stronger in most cases, and a lot stronger in others!

birdracerthree wrote:

I’ve had enough stalling… I’m switching to list-contains in the evaluation and removing mate evaluations entirely unless a mate is found. Then, the TTable is toggled off and mate evals are turned on (or I gradually reduce the depth with the TTable List-Contains). Element desperately needs LMR to keeps up with White Dove’s tactical vision. Thoughts?

ArnoHu wrote:

birdracerthree wrote:

I’ve had enough stalling… I’m switching to list-contains in the evaluation and removing mate evaluations entirely unless a mate is found. Then, the TTable is toggled off and mate evals are turned on (or I gradually reduce the depth with the TTable List-Contains). Element desperately needs LMR to keeps up with White Dove’s tactical vision. Thoughts?

Not sure I understand correctly about TT mate evaluations, but I know they can be challenging. LMR is important from a certain search depth on.

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

I’ve had enough stalling… I’m switching to list-contains in the evaluation and removing mate evaluations entirely unless a mate is found. Then, the TTable is toggled off and mate evals are turned on (or I gradually reduce the depth with the TTable List-Contains). Element desperately needs LMR to keeps up with White Dove’s tactical vision. Thoughts?

Not sure I understand correctly about TT mate evaluations, but I know they can be challenging. LMR is important from a certain search depth on.

I can’t fix the TT mate eval issue, so I’m removing them when the TTable is on. The LMR is to keep up with White Dove’s search depth. Detecting king captures in the evaluation will cause issues…

Quick question; why are move generation lookups faster than the more standard method? The latter uses numerical calculations, so it should be faster.

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

I’ve had enough stalling… I’m switching to list-contains in the evaluation and removing mate evaluations entirely unless a mate is found. Then, the TTable is toggled off and mate evals are turned on (or I gradually reduce the depth with the TTable List-Contains). Element desperately needs LMR to keeps up with White Dove’s tactical vision. Thoughts?

Not sure I understand correctly about TT mate evaluations, but I know they can be challenging. LMR is important from a certain search depth on.

I can’t fix the TT mate eval issue, so I’m removing them when the TTable is on. The LMR is to keep up with White Dove’s search depth. Detecting king captures in the evaluation will cause issues…

Quick question; why are move generation lookups faster than the more standard method? The latter uses numerical calculations, so it should be faster.

Hm, the standard move generation method on any other platform would be bitboards. As we don't have 64bit integers nor bitwise ops, what comes closest are precalculated lookup tables, as they limit the number of Scratch blocks invoked, which is the most important performance factor on Scratch 3. On TurboWarp that is not the case, but lookup tables should also be faster than additional logic code.

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

ArnoHu wrote:

birdracerthree wrote:

I’ve had enough stalling… I’m switching to list-contains in the evaluation and removing mate evaluations entirely unless a mate is found. Then, the TTable is toggled off and mate evals are turned on (or I gradually reduce the depth with the TTable List-Contains). Element desperately needs LMR to keeps up with White Dove’s tactical vision. Thoughts?

Not sure I understand correctly about TT mate evaluations, but I know they can be challenging. LMR is important from a certain search depth on.

I can’t fix the TT mate eval issue, so I’m removing them when the TTable is on. The LMR is to keep up with White Dove’s search depth. Detecting king captures in the evaluation will cause issues…

Quick question; why are move generation lookups faster than the more standard method? The latter uses numerical calculations, so it should be faster.

Hm, the standard move generation method on any other platform would be bitboards. As we don't have 64bit integers nor bitwise ops, what comes closest are precalculated lookup tables, as they limit the number of Scratch blocks invoked, which is the most important performance factor on Scratch 3. On TurboWarp that is not the case, but lookup tables should also be faster than additional logic code.

Ok, why are lookup tables faster than using operators? A lookup table is put into a Boolean, but a small set of operators should be faster (mod for edge detection for example).

ArnoHu wrote:

In the latest GoK version, I reduced the effect of mobility evaluation significantly. I think it simply generated too much noise. The mistake was that I tried which values would prevent trapped queens or rooks, but the same values might just screw up positional evaluation when there is no real danger despite reduced mobility.

In a first test game, GoK (Medium, white) took on Element (6+8), and played a perfect game, winning in 40 moves. Element played great too, its only blunder was not considering en-passant: https://lichess.org/fUuTd7NV#79

ArnoHu wrote:

ArnoHu wrote:

In the latest GoK version, I reduced the effect of mobility evaluation significantly. I think it simply generated too much noise. The mistake was that I tried which values would prevent trapped queens or rooks, but the same values might just screw up positional evaluation when there is no real danger despite reduced mobility.

In a first test game, GoK (Medium, white) took on Element (6+8), and played a perfect game, winning in 40 moves. Element played great too, its only blunder was not considering en-passant: https://lichess.org/fUuTd7NV#79

Next game against White Dove (P4), one GoK mistake at move 39, which won't happen on Difficult, otherwise a fine game. GoK wins it at 93%: https://lichess.org/aMRTvOU7#107

S_P_A_R_T wrote:

ArnoHu wrote:

ArnoHu wrote:

In the latest GoK version, I reduced the effect of mobility evaluation significantly. I think it simply generated too much noise. The mistake was that I tried which values would prevent trapped queens or rooks, but the same values might just screw up positional evaluation when there is no real danger despite reduced mobility.

In a first test game, GoK (Medium, white) took on Element (6+8), and played a perfect game, winning in 40 moves. Element played great too, its only blunder was not considering en-passant: https://lichess.org/fUuTd7NV#79

Next game against White Dove (P4), one GoK mistake at move 39, which won't happen on Difficult, otherwise a fine game. GoK wins it at 93%: https://lichess.org/aMRTvOU7#107

I've tested WD v7.05 (which just got released) and it seems to find the miracle draw here!

ArnoHu wrote:

Earlier today I uploaded a GoK version which calculates attack tables before EVERY full search move generator run (OK not every run, as attack tables are cached in transposition table), something I had disabled years ago due to performance reasons. But GoK is faster today, and this approach allows its staged move generator to find all MVV/LVA captures with specialized code taking only a fraction of time; in addition, move ordering is better, hence pruning / LMR is better, king ring attacks will always be up-to-date for evaluation. Overall search performance stayed the same, but search quality has improved.

As a side-effect, average MPS on TurboWarp fell from 250,000 to 200,000, and NPS from 200,000 to 150,000 (although we are reaching the same search depth as before). Attack tables are created based on generated moves though, so just for fun I temporarily added attacks to MPS statistics - and it went up to 750,000 MPS.