Here is a test version of texel with an extra UCI option "TBSwindle". If you set it to false all TB probes that return "draw" are evaluated as 0. Note that this is still not equivalent to what stockfish does, because Ronald said stockfish prefers cursed wins over "regular" draws.
It doesn't seem to have an effect. This is the old result:
Score of SF7 No TB vs Texel 1.06 No TB: 291 - 74 - 353 [0.651] 718
ELO difference: 108
Finished match
Score of SF7 Syzygy vs Texel 1.06 Syzygy: 257 - 166 - 295 [0.563] 718
ELO difference: 44
Finished match
And the new result with Syzygy Swindle=false within error margins of the old Syzygy result:
petero2 wrote:Another difference is that texel has "TB swindle mode" permanently enabled, which means that it does not give a 0 score for a TB draw. Cursed wins are scored between 0.35 and 0.70 depending on how far away they are from a real win, and "normal draws" are scored between 0 and 0.34 depending on how good texel's normal search+eval think the position is. (And correspondingly for negative scores between 0 and -0.70).
This is not going to help if both engines play with TBs. SF+TB will know that a cursed win is a draw and that a blessed loss is a draw.
SF+TB does have a slight preference for reaching a cursed TB win over a TB draw and for reaching a TB draw over a cursed TB loss, but against an engine that correctly uses the same TBs that will not help at all. SF won't be able to swindle the opponent engine and SF won't be swindled by the opponent engine.
I think it could in theory help if the root position is not in the TB and texel searches deep enough to hit the TB but the opponent does not search deep enough to hit the TB. Texel's swindle mode is enabled even if the root position is not a TB position.
Well, if Texel finds a cursed win deep in the tree and manages to steer the game to that cursed win position, against SF+TB the game is certain to end in a draw. This does not depend on how well SF+TB searches but results from SF+TB being able to defend that (from its point of view) blessed loss.
I guess steering towards a cursed win against a weak opponent that is using TB could increase the chances of the opponent making a mistake before the position gets into the TB, and that that mistake would let texel find a forced TB win. I think this is extremely unlikely to happen when texel plays against stockfish though.
But also against weaker engines it would seem better to avoid the conversion into the cursed TB win in the hope of finding a real win. On the other hand, an evaluation of +0.70 or less should usually deter the engine from entering the cursed win if it has an advantage that might be winning.
In any event, we agree that against SF this is very unlikely to make a difference.
Laskos wrote:Do you have a reason for Texel implementation of Syzygy being better than Stockfish one?
If Stockfish profits less, it is because Stockfish has less need for them when playing these endgames.
The result seems too peculiar in its magnitude.
Why?
You were right, it seems the entire effect is due to strength difference. I equaled the strength of Texel and Stockfish on these hard 6-men positions without TB, giving time-odds Stockfish at 3''+0.03'' versus Texel at 60''+0.6'':
Score of SF7 No TB vs Texel 1.06 No TB: 170 - 160 - 388 [0.507] 718
ELO difference: 5
Finished match
Now adding Syzygy 5-men bases to both doesn't produce the effect, the second result is within error margins of the first one, both engines profit equally form bases:
Laskos wrote:Wow, Little Blitzer is buggy when adjudicating 50 move draw. The missed Win cases are hard to reproduce. I will check later this night when I get back home.
Although for Wins I am still getting some draws with Texel (one in 500 games or so) in Cutechess-cli, I observe some odd behavior, the draws seem to cluster and appear at the start of the run. Also, the wrong move is the first move in the game. I guess it's UI-engine communication. Here are 2 games:
After 0.42 seconds texel had not been able to finish the depth 2 search. I guess this happens because the DTZ files are on a mechanical disk and they have not been used recently enough to be in cache. The texel TB implementation prefers to not use TBs if it would overstep the allocated thinking time too much, but the stockfish implementation would probe DTZ at the root regardless of how much time that would take I think.
So this seems to be a combination of using hyper bullet time control, starting from a position already in the TBs, having the DTZ tables on a slow (mechanical) disk drive, and using an engine that prefers not using the TBs over using too much thinking time.
In a game not starting from a TB position, the first DTZ probe in texel would typically happen inside a deep search when texel has proven a TB win and starts trying to optimize the DTM score. Using the same hardware, there would likely be 0.42s delay there too, but that would not really matter because the search has already found a forced win, and when starting a new search after the opponents next move, the required part of the DTZ table would already be cached.
There might also be some lag on a HDD if in energy saver mode, and it needs time to spin up. This might happen if WDL is on SSD, but DTZ on a HDD that is not accessed except later in the game.
i7-5930K @4.5GHz, H100i Hydro Cooler, 64GB DDR4 Corsair Dominator Platinum @3000MHz, ASUS X99 Deluxe mboard, 1TB EVO 850 SSD
Arpad Rusz wrote:If a user wants to analyze a position seting MultiPV to some value N, that means he/she would like to see N variations, no matter what! (Of course, with the only exception of not having enough legal moves).
I have now fixed this in Cfish.
Instead of using TBs to filter out suboptimal moves at the root, TBs are now used to rank and sort all root moves. The multipv loop then limits its search each time to a group of root moves of equal rank.
If multipv is set to 1, only the top-ranked root moves are searched, which is exactly the old behaviour.
I may look into porting this to Stockfish, since it actually seems to simplify a few things.
