Triple Brain

[Jaimes Conda]

''one of the features of the "Classic Shredder 6"
interface was the "Triple Brain" analysis features.
So two engines analyse a position and a third engine called
the "Triple Brain" acts as arbiter and uses the analysis of the
other two engines, to determine what line of play is best in that position.

I copied this question from the Rubka forum. And think the question is valid in so far as it could apply to all chess software.
Has the "Triple Brain" idea been developed and shown to be an advantage?

Jaimes

[Dann Corbit]

''one of the features of the "Classic Shredder 6"
interface was the "Triple Brain" analysis features.
So two engines analyse a position and a third engine called
the "Triple Brain" acts as arbiter and uses the analysis of the
other two engines, to determine what line of play is best in that position.

I copied this question from the Rubka forum. And think the question is valid in so far as it could apply to all chess software.
Has the "Triple Brain" idea been developed and shown to be an advantage?

Jaimes

It seems that the basic concept could prove useful in a highly parallel environment.

For example, we could have chest examine pv nodes to see if any were mates (in either direction) and if SMP started to saturate around 32 CPUs and we had hundreds available, it might be nice to have dozens of engines analyzing with 32 CPUs each and have an arbitrer look at their outputs for brilliancies or perhaps voting purposes.

[Ovyron]

it might be nice to have dozens of engines analyzing with 32 CPUs each and have an arbitrer look at their outputs for brilliancies or perhaps voting purposes.

Voting doesn't work. As you can see, sometimes the positions analyzed with Rybka are only understood by Rybka, this is the reason that it beats all other engines. So, on a voting environment, some engines that are wrong may outvote the Rybka's right evaluation, and you get detrimental results.

The Arbiter may work better, but you need engines about the same strength with different styles, and a good arbiter.

[Dann Corbit]

it might be nice to have dozens of engines analyzing with 32 CPUs each and have an arbitrer look at their outputs for brilliancies or perhaps voting purposes.

Voting doesn't work. As you can see, sometimes the positions analyzed with Rybka are only understood by Rybka, this is the reason that it beats all other engines. So, on a voting environment, some engines that are wrong may outvote the Rybka's right evaluation, and you get detrimental results.

The Arbiter may work better, but you need engines about the same strength with different styles, and a good arbiter.

The vote chooser/arbiter should also look at the evals (and possibly scale for the engine, since {for example} Rybka evals are lower than other engines).

E.g.:
Engine 1 likes move x, score +5 centipawns
Engine 2 likes move x, score +7 centipawns
Engine 3 likes move q, score -16 centipawns
Engine 4 likes move t, score +160 centipawns

if we have confidence in engine 4, we choose move t, even though Engines 1 and 2 agree.

[Ovyron]

Uri's idea also included looking at the score's story. For example, if engine A has shown a 0.00 score for a while, and engine B shows a +1.25, but that +1.25 is not rising, it's probably because engine B doesn't really understand the position and engine A does, so the arbiter should give more confidence to engine A.