Taken from CCC (Stockfish & mainlines)

[Rebel]

From an implementation point of view this way is much more streamlined and easy to understand and to follow, but I concede that is not a _perfect_ solution and in some cases you miss info.

The reason why I prefer this to "triangular array" is that is much more simpler to implement and it works at least equally well in real games.

Not to make philosopy but many choices in engine search are based on approximations or on things that can be inaccurate, this is very fundamental in how an engine works, so deem a technique bad just because is innaccurate sometime is not enough IMO, once again the only metrics is how it performs in real games. Instead it is a fact that is much more simpler then alternative solutions.

Hint: why not maintain a "triangular array" main-line till 8 plies (or so) and use that one if it is longer than the one extracted from the HT?

The processor costs are zero, only disadvantage: you won't win the beauty-world-cup for clear programming this year.

Ed

[mcostalba]

Once you have the triangular array code you may well use it for any ply (the performance impact is small anyway) and you avoid to add a trick on top of an already good bunch of code.

I agree doing like this you miss the "beauty-world-cup for clear programming", but unfortunatly that cup is the only one I am really motivated to win even more then the ELO cup.

This perhaps is not the case, but as a general approach I have experienced that if you keep code simple and clear today, even giving up to some possible optimization, you pave the way for easily adding new features tomorrow....and the net balance turns out to be positive in the long term.

[hyatt]

Once you have the triangular array code you may well use it for any ply (the performance impact is small anyway) and you avoid to add a trick on top of an already good bunch of code.

I agree doing like this you miss the "beauty-world-cup for clear programming", but unfortunatly that cup is the only one I am really motivated to win even more then the ELO cup.

This perhaps is not the case, but as a general approach I have experienced that if you keep code simple and clear today, even giving up to some possible optimization, you pave the way for easily adding new features tomorrow....and the net balance turns out to be positive in the long term.

I don't find the "triangular array" code to be very messy at all. And the benefit is that you get a PV that leads to an endpoint that produces the backed-up score. A plus for debugging. Having a bogus PV that doesn't match the endpoint score makes life more complicated, not less so.