Can somebody do simply this? By far the strongest engine!

[khalidomar]

Fritz 15 refuses to switch to Komodo from move 36 or whatever to the end.

I'm guessing you are testing with a short time control? Chimera will not switch engines if the remaining game time is less than the SwitchingOverheadSeconds which has a default value of 30 seconds. This is to avoid time loss situations if the new engine needs time to initialize.

The SwitchingOverheadSeconds is not configurable from Chimera GUI but you can edit it manually in the XML.

Try playing a longer TC or reduce the SwitchingOverheadSeconds to a smaller value and see if it works.

EDIT: What are these "Username" and "Password"?

Username and Password are only needed if you want to run the engine under a different Windows user account. This is the case when running engines that use Microsoft MPI to run a cluster of engines on two or more machiens. If you are not running a cluster, then you should leave the username/password fields empty

[Laskos]

Fritz 15 refuses to switch to Komodo from move 36 or whatever to the end.

I'm guessing you are testing with a short time control? Chimera will not switch engines if the remaining game time is less than the SwitchingOverheadSeconds which has a default value of 30 seconds. This is to avoid time loss situations if the new engine needs time to initialize.

The SwitchingOverheadSeconds is not configurable from Chimera GUI but you can edit it manually in the XML.

Try playing a longer TC or reduce the SwitchingOverheadSeconds to a smaller value and see if it works.

EDIT: What are these "Username" and "Password"?

Username and Password are only needed if you want to run the engine under a different Windows user account. This is the case when running engines that use Microsoft MPI to run a cluster of engines on two or more machiens. If you are not running a cluster, then you should leave the username/password fields empty

Hmmm, it didn't work in Fritz 15 anyway (setting SwitchingOverheadSeconds to 0 or 1) and I went to all the trouble to install Fritz 17 which I intentionally avoided to install on my new windows setup because it modifies the NVIDIA components and drivers. In Fritz 17 it works, with 1-2 move delays at 1'+1'', now Lc0_SV_1541 net + Komodo_14 from move 36 is simply destroying SF_11. I am curious if by overwriting NVIDIA components, now it will work in Cutechess-CLI too. Does this "Overhead" accept fractional values like 0.25s or even 0s? In Cutechess-CLI I am often using very fast games.

I hope Ferdinand writes something simpler, I am not sure why this thing doesn't work in Fritz 15 and works in Fritz 17 with its driver components and such.


EDIT: look at this intermediate result, when it works in Fritz 17:

[khalidomar]

Hmmm, it didn't work in Fritz 15 anyway (setting SwitchingOverheadSeconds to 0 or 1) and I went to all the trouble to install Fritz 17 which I intentionally avoided to install on my new windows setup because it modifies the NVIDIA components and drivers. In Fritz 17 it works, with 1-2 move delays at 1'+1'', now Lc0_SV_1541 net + Komodo_14 from move 36 is simply destroying SF_11. I am curious if by overwriting NVIDIA components, now it will work in Cutechess-CLI too. Does this "Overhead" accept fractional values like 0.25s or even 0s? In Cutechess-CLI I am often using very fast games.

I hope Ferdinand writes something simpler, I am not sure why this thing doesn't work in Fritz 15 and works in Fritz 17 with its driver components and such.

There is no difference between Fritz 17 and Fritz 15 as far as the UCI protocol is concerned. If it works with Fritz 17 then it should work with Fritz 15. Something else must be going on! (Did you change the XML manually in Fritz 15 while the engine is loaded/playing? it will not work that way as it needs to load again and read the configs at startup)

I have tested Chimera on Fritz 16 only, but I know others have tested it with various Fritz/Chessbase/Playchess versions, InfinityChess, Arena, CuteChess, Octagon, etc...

Eman Chimera is complient with the UCI protocol therefore it works with any GUI that supports UCI

The SwitchingOverheadSeconds is an integer and it does not accept fractions. If you want to completely disable it (although not recommended) then you can set it to a negative value.

[Rebel]

I am unaware of a hybrid engine of the simplest kind, and I don't know what's the matter. Somebody better than me at coding can do this in an hour.
Simply: play using Lc0 first 35 moves and using SF after 35 moves to the end. On some RTX GPU and 4 to 32 core machine this combo will be by far the best engine.

Here are my results with RTX 2070 and 4 strong i7 cores:

200 games each match

Pure Lc0 net SV_3200 --- versus SF_11:
99/200

Combo Lc0 net SV_3200 to move 35, SF_11 after move 35 --- versus SF_11
123/200

An 85 Elo points improvement over pure Lc0.

As simple as that.
Lc0 is ridiculous in endgames, it always was and will probably improve only a little. In 200 games against Fritz 5.32, SF_11 scored 200/200, while Lc0 SV_3200 scored 193/200, Lc0 failing to convert in endgames 14 totally won positions even against Fritz 5.32 !!! It's ridiculous.

Are there volunteers to build such a combo engine in a matter of an hour?

This is, what you are looking for, isnt it?

Eman Chimera (previously known as Hybrid UCI) is a tool to run two or more UCI engines (one after another) to play the same game. Eman Chimera will switch to the appropriate engine based on move number of the current game being played

https://eman.zohosites.com/files/Eman%2 ... 0v1.10.zip

I know, that on playchess, some people use it, and SF takes over after 60 moves (35 moves seems a bit too early to me). So, it works in the FritzGUI. And what works in there, should run everywhere...

The switch should be done by the position on the board. About 6-8 months I wrote such a tool. SF10 and Lc0 both thinking, see screenshot below and then a simple referee program (I used ProDeo) makes the decision, in this board position, since it's the endgame, it takes the SF10 move, else the Lc0 move.

http://rebel13.nl/ZeroFishx.jpg

Hi Ed,
Is this tool still up for download?
Thanks!

It never was available because I lost interest while it wasn't ready for release. Things like time control and draws by repetition etc. But it works and Kai's observation is quite to the point.

Ed, I don't need any fancy things like "third brain" and such, just that after a set number of moves or a set number of men on the board, SF replaces Lc0. As simple as that. If I get 85 +/- 30 Elo points in first try doing this by hand, it's better than anything hybrid I have seen so far. One has to get rid of Lc0 silly endgames. I have seen it quite often failing to convert won endgames against Fritz 5.32, it's hilarious! Can you do that and wrap it in an EXE as an UCI compatible engine, making sure that the overhead is small? Maybe I will try to contact Ferdinand Mosca, he was always kind to provide me with tools for experiments, and here one talks of building the strongest Chess engine all around.

I understand your fascination with your awareness that SF plays the better endgame. My point was that you can do a lot more than that alone.

[Laskos]

I am unaware of a hybrid engine of the simplest kind, and I don't know what's the matter. Somebody better than me at coding can do this in an hour.
Simply: play using Lc0 first 35 moves and using SF after 35 moves to the end. On some RTX GPU and 4 to 32 core machine this combo will be by far the best engine.

Here are my results with RTX 2070 and 4 strong i7 cores:

200 games each match

Pure Lc0 net SV_3200 --- versus SF_11:
99/200

Combo Lc0 net SV_3200 to move 35, SF_11 after move 35 --- versus SF_11
123/200

An 85 Elo points improvement over pure Lc0.

As simple as that.
Lc0 is ridiculous in endgames, it always was and will probably improve only a little. In 200 games against Fritz 5.32, SF_11 scored 200/200, while Lc0 SV_3200 scored 193/200, Lc0 failing to convert in endgames 14 totally won positions even against Fritz 5.32 !!! It's ridiculous.

Are there volunteers to build such a combo engine in a matter of an hour?

This is, what you are looking for, isnt it?

Eman Chimera (previously known as Hybrid UCI) is a tool to run two or more UCI engines (one after another) to play the same game. Eman Chimera will switch to the appropriate engine based on move number of the current game being played

https://eman.zohosites.com/files/Eman%2 ... 0v1.10.zip

I know, that on playchess, some people use it, and SF takes over after 60 moves (35 moves seems a bit too early to me). So, it works in the FritzGUI. And what works in there, should run everywhere...

The switch should be done by the position on the board. About 6-8 months I wrote such a tool. SF10 and Lc0 both thinking, see screenshot below and then a simple referee program (I used ProDeo) makes the decision, in this board position, since it's the endgame, it takes the SF10 move, else the Lc0 move.

http://rebel13.nl/ZeroFishx.jpg

Hi Ed,
Is this tool still up for download?
Thanks!

It never was available because I lost interest while it wasn't ready for release. Things like time control and draws by repetition etc. But it works and Kai's observation is quite to the point.

Ed, I don't need any fancy things like "third brain" and such, just that after a set number of moves or a set number of men on the board, SF replaces Lc0. As simple as that. If I get 85 +/- 30 Elo points in first try doing this by hand, it's better than anything hybrid I have seen so far. One has to get rid of Lc0 silly endgames. I have seen it quite often failing to convert won endgames against Fritz 5.32, it's hilarious! Can you do that and wrap it in an EXE as an UCI compatible engine, making sure that the overhead is small? Maybe I will try to contact Ferdinand Mosca, he was always kind to provide me with tools for experiments, and here one talks of building the strongest Chess engine all around.

I understand your fascination with your awareness that SF plays the better endgame. My point was that you can do a lot more than that alone.

In one year nobody (aside Chimera) improved the best engine (with an RTX GPU) Lc0 by 80 Elo points as I derived from a hand-made test (and confirmed now in Fritz GUI). I also understand that there are many topics to understand and go deep, I want results, as simple as that.

[Laskos]

Hmmm, it didn't work in Fritz 15 anyway (setting SwitchingOverheadSeconds to 0 or 1) and I went to all the trouble to install Fritz 17 which I intentionally avoided to install on my new windows setup because it modifies the NVIDIA components and drivers. In Fritz 17 it works, with 1-2 move delays at 1'+1'', now Lc0_SV_1541 net + Komodo_14 from move 36 is simply destroying SF_11. I am curious if by overwriting NVIDIA components, now it will work in Cutechess-CLI too. Does this "Overhead" accept fractional values like 0.25s or even 0s? In Cutechess-CLI I am often using very fast games.

I hope Ferdinand writes something simpler, I am not sure why this thing doesn't work in Fritz 15 and works in Fritz 17 with its driver components and such.

There is no difference between Fritz 17 and Fritz 15 as far as the UCI protocol is concerned. If it works with Fritz 17 then it should work with Fritz 15. Something else must be going on! (Did you change the XML manually in Fritz 15 while the engine is loaded/playing? it will not work that way as it needs to load again and read the configs at startup)

I have tested Chimera on Fritz 16 only, but I know others have tested it with various Fritz/Chessbase/Playchess versions, InfinityChess, Arena, CuteChess, Octagon, etc...

Eman Chimera is complient with the UCI protocol therefore it works with any GUI that supports UCI

The SwitchingOverheadSeconds is an integer and it does not accept fractions. If you want to completely disable it (although not recommended) then you can set it to a negative value.

Ok, I see now. Chimera accepts only regular books or PGNs as openings, not EPD files and not "fake" PGNs as 2moves_v1.pgn of SF framework. I was always using either 2moves_v1.pgn or EPD files, and for the first time a regular CTG book in Fritz 17. Adding EPD support would be helpful.

[khalidomar]

Ok, I see now. Chimera accepts only regular books or PGNs as openings, not EPD files and not "fake" PGNs as 2moves_v1.pgn of SF framework. I was always using either 2moves_v1.pgn or EPD files, and for the first time a regular CTG book in Fritz 17. Adding EPD support would be helpful.

The opening book/suite (PGN or EPD) is totally handled by the GUI you are using. Chimera is only invoked by the GUI when the book has no more moves or at the end of the opening line from PGN opening suite or from EPD (i'm not very familiar with EPD)

Chimera receives position command from the GUI which tells it about the current board setup, following the position command is usually a go command to let the engine start the thinking.

If your PGN opening suite/EPD contains FEN strings that does not have the actual current move number then that explains why Chimera is not switching at move 36 when it should!

Just to elaborate, consider the following FEN strings:

• 4r1k1/5pp1/P2P4/1p2p2p/7N/5r1P/5n1K/1R1R4 b - - 0 34
• 4r1k1/5pp1/P2P4/1p2p2p/7N/5r1P/5n1K/1R1R4 b - - 0 1

Both FEN strings represent the exact same board setup but the first one states that the current move number is 34 while the second one states that the current move number is 1

Both FEN strings are valid and acceptable by GUI's and engines. But the second FEN string is going to mislead Chimera becasue it does not tell it what is the real move number and therefore Chimera will not switch to the next engine when you expect it to.

Again, I'm not familiar with EPD because it is not part of the official UCI protocol, but if EPD consists of FEN strings or something similar to it then it is possible that the move numbers there are not accurate which is causing Chimera to fail to switch when it should

[Laskos]

Ok, I see now. Chimera accepts only regular books or PGNs as openings, not EPD files and not "fake" PGNs as 2moves_v1.pgn of SF framework. I was always using either 2moves_v1.pgn or EPD files, and for the first time a regular CTG book in Fritz 17. Adding EPD support would be helpful.

The opening book/suite (PGN or EPD) is totally handled by the GUI you are using. Chimera is only invoked by the GUI when the book has no more moves or at the end of the opening line from PGN opening suite or from EPD (i'm not very familiar with EPD)

Chimera receives position command from the GUI which tells it about the current board setup, following the position command is usually a go command to let the engine start the thinking.

If your PGN opening suite/EPD contains FEN strings that does not have the actual current move number then that explains why Chimera is not switching at move 36 when it should!

Just to elaborate, consider the following FEN strings:

• 4r1k1/5pp1/P2P4/1p2p2p/7N/5r1P/5n1K/1R1R4 b - - 0 34
• 4r1k1/5pp1/P2P4/1p2p2p/7N/5r1P/5n1K/1R1R4 b - - 0 1

Both FEN strings represent the exact same board setup but the first one states that the current move number is 34 while the second one states that the current move number is 1

Both FEN strings are valid and acceptable by GUI's and engines. But the second FEN string is going to mislead Chimera becasue it does not tell it what is the real move number and therefore Chimera will not switch to the next engine when you expect it to.

Again, I'm not familiar with EPD because it is not part of the official UCI protocol, but if EPD consists of FEN strings or something similar to it then it is possible that the move numbers there are not accurate which is causing Chimera to fail to switch when it should

Yes, that's the problem. My EPD opening files contain FENs which do not have move number tags at all and so is 2moves_v1.pgn "games", containing an initial FEN, no move tags and no moves. Can you make Chimera to assume that these are 0-movers, just like the initial starting position?

[Milos]

I know, that on playchess, some people use it, and SF takes over after 60 moves (35 moves seems a bit too early to me). So, it works in the FritzGUI. And what works in there, should run everywhere...

The switch should be done based on material left on board and mobility of material left on board (and/or number of free pawns), not simply by move number. This could even be nicely auto-tuned for each TC.

[Dann Corbit]

I know, that on playchess, some people use it, and SF takes over after 60 moves (35 moves seems a bit too early to me). So, it works in the FritzGUI. And what works in there, should run everywhere...

The switch should be done based on material left on board and mobility of material left on board (and/or number of free pawns), not simply by move number. This could even be nicely auto-tuned for each TC.

I agree with Milos. You can be twenty some moves into the game with only one or two captures and you can have firecracker exchanges and have half the chessmen gone. It is the endgame phase we are looking for. I am sure that nobody's chess program decides we are in the endgame just based on plies.