human games against ElephantGambit v0.7.0

[tissatussa]

today i won 3 games against ElephantGambit

the first game was a hard struggle .. in the end ElephantGambit just gave me a full Rook for nothing, so i won that game .. how could this happen ?

the second and third game i sacrificed a Rook on the h-file and gave mate. Such rather long-term tactics seem to deep for ElephantGambit. Btw. i also lost some games ..

---

how is the development going ?

[looak]

Hello hi, Development has been slow, been swamped with work and family visiting so I haven't worked any on this project. I'm happy to hear that you still enjoy playing my engine. :) It gives me the motivation to start working on this again; maybe I'll have an update in the coming few days. :)

[tissatussa]

yeah, i remember you were just getting the gist of it, and i wondered if the latest version was really stronger then the previous one ..

lately i'm following another new simple engine, see this post : https://github.com/boettcherb/DeepBlunder-Chess-Engine/issues/2 the author made really good progress and uses "my" logo !

[looak]

Neat - I like the logo too. ;)

With your games, do you have a PGNs for them? I can input that into my engine to "replay" the game and output the evaluated positions.

[tissatussa]

i have the PGN of many ElephantGambit games, also before v0.7.0 what do you mean by "replay" and output positions ?

[looak]

Oh, how nice, I'd love some of the ones where Elephant is giving away free pieces.

I'm working on a change where I can input the PGN string example: 1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 d6 8. c3 O-O 9. h3 Nb8 10. d4 Nbd7 and have the engine output, from each position, the evaluation and also the best move. And by doing so, have a place to start when trying to figure out why it thought the rook move was a good idea.

[tissatussa]

..and have the engine output, from each position, the evaluation and also the best move..

the variation you give is the standard Spanish Opening, Ruy Lopez .. you could also have given the FEN position after these moves.

..have a place to start when trying to figure out why it thought the rook move was a good idea..

i think that wrong Rook move is due to mismanagement of the hash table. i didn't try it, but i'm almost sure you can not reproduce the concerning 'bestmove' : when letting ElephantGambit think about the position, it will not decide that Rook move .. did you try it ?

should i send those PGNs ?

[looak]

I did not try it; if it is the case with the hash table, the game must be played from the start to be deterministic since the hashtable is kept per game.

I have not replayed the game as in the gif yet, would rather have the computer replay it with a PGN. :)

Hope you're having a great week!

[tissatussa]

..if it is the case with the hash table, the game must be played from the start to be deterministic since the hashtable is kept per game.

I don't understand what you mean. It seems you think it's possible to reproduce the error, but it isn't. Although ElephantGambit may always play the same bestmove in each position (within the given time control), the hash will be different and also the opponent may not play the same moves. Btw. here are those 3 games : 3-elephant-gambit-games.zip

ElephantGambit doesn't display its PV lines at each depth during the game, you should fix that first. Then it will show which bestmoves it's considering in any position, but i bet the strange "Rook gift" will not be traceable.

[tissatussa]

43-elephantgambit-v0.7.0-games.zip

[looak]

You are correct, but given the exact same parameters and sequence of moves, the engine should be playing the exact same result move. Even if there's a bug present, it should be completely deterministic. I.e., there is no fuzzy logic to determine what move to evaluate where two results have the same value.

It might be that I'll need to output the time control, time used or time left for each move to narrow it down.

On another note, I've wondered what the best approach would be for multi-pv, do you go deep on the "second best move"?

Thank you for everything!

[tissatussa]

..the engine should be playing the exact same result move..

maybe you're right, it sounds logical .. but do you use Hash ? How is it implemented ? Indeed when the Hash mechanism functions exactly the same each game, the error should be traceable when the "Rook gift" occurs.

..what the best approach would be for multi-pv, do you go deep on the "second best move"?

good question, i don't know how Multi-PV can be implemented .. it seems tricky and not obvious .. you should investigate and maybe ask other programmers how they did it .. i can send you a list of C++ engines having MPV, i gather them :-) Once i convinced the author of Weiss to implement it (it's a C engine, not C++).

[looak]

It is critical that the hash algorithm is 100% deterministic, otherwise things would break significantly. I've implemented so-called Zorbist Hashing: https://en.wikipedia.org/wiki/Zobrist_hashing, the beauty of it is that you can change individual pieces, remove and re-add them, with simple bitwise operations and you'll get the same result. For example, given any position:

Gives you hash A. Removing the White Queen from G4 will give you hash B. Re-adding the White Queen to G4 will give you hash A again. Moving White Queen from G4 to E4 will give you hash C. Taking this position as a fen, I restart the engine Load the fen and I'll get hash C again.

100% reproducible and deterministic. Beautiful :)

[tissatussa]

I've implemented so-called Zorbist Hashing

i read some about that, but never used it myself. hope your tests succeed !

[tissatussa]

about MultiPV : i find a lot of info at https://www.chessprogramming.org/Principal_Variation plus links .. i guess you found that page :-)

[tissatussa]

MultiPV : why not try to write some own search mechanism which reflects your understanding of it ? , not following other authors - but maybe your implementation turns out to be same !?

[looak]

Yea, thanks for the advice! I've been reading a bit about it and have an idea. Will let you know how it goes.

[tissatussa]

I've been reading a bit about it and have an idea

i saw you implemented threads, there's an UCI options for it. are they involved in your MPV idea ? (you don't have to explain the idea) many engines don't use multi-threading, probably because this is not easy to implement .. but it's another technique to make a chess engine run faster, am i right ?

today i was reading a bit about the Meson build system, like make and cmake .. i managed to compile a few existing chess engines with it (by writing a meson.build file for each code folder). Now i'm studying how to build a Rust engine with it, that's also possible .. this way i learned a lot and i think it's useful for future projects .. do you know Meson ? It's promising but not very well documented.

[tissatussa]

I just stumbled upon this text concerning the Torch engine :

One such example: Torch has a heavily modified alpha beta search, which allows a sort of multi-multi-multi-...-pv. We're able to extract a large number of lines from the search in a single search, and we're going to use that to provide humans a better experience when reviewing their games -- avoiding giving confusing engine lines that are only marginally better than what a strong player would have done.

It's written by its author Andrew Grant, see End of the Torch Experiment, he's famous for the Ethereal engine and the SPRT testing framework OpenBench. Torch is very strong, it can beat Leela and even SF. From the start is has been a closed project, initiated by Chess.com - on the CCRL rating lists Torch is a 'private engine'.

But today i found a GitHub page () which supplies a copy of the source (although it seems not complete) and asset binaries for Linux and Windows. The Linux one just works, it won a 5m+3s game against some 3000+ .. Maybe this is all illegal stuff ? ) also some Komodo version is supplied there, v3.3 32-bit (?)

[tissatussa]

In a 5m+3s game Torch played Black, and White did Qa4+ here :

The only good move Black can do is Nc6, blocking the check and defending Bb4 at the same time. Still Torch thought for 5.6 seconds, i think that's long, Nc6 is the only move. So i wondered how other engines would act here :

rnbqk2r/ppp2ppp/4pn2/3p4/QbPP4/2N2N2/PP2PPPP/R1B1KB1R b KQkq - 3 5 5m+3s

ElephantGambit v0.7.0    16 sec
Stockfish 16 NNUE        15 sec
Torch v2                  8 sec
Komodo Dragon NN          6 sec

What does this data set tell us ? (i can test more engines) Anyhow, SF spends 15 seconds !? Could ElephantGambit do better ? :-)