multi-dimensional piece/square tables

[Tony P.]

Sorry for necromancy - I want to credit Pawel for considering PSTs involving more than 1 piece location.

I've stumbled upon a 2018 preprint 'Comparison Training for Computer Chinese Chess' (the final version of the article was published in IEEE Transactions on Games in January 2019) by Wen-Jie Tseng, Jr-Chang Chen, I-Chen Wu, and Ting-Han Wei, who claimed that their modifications of a xiangqi engine Chimo that included eval features that they denoted as LOC2 - features that indicated pairwise interactions of pieces, could be indexed by [piece1color][piece1type][piece1square][piece2color][piece2type][piece2square], for many or even all the pairs of pieces - performed clearly better at very fast TC (0.4 sec/move on Intel Core i5-4690) than the modifications that didn't include such features, despite the former modifications (denoted as EVAL10-13) having >120K eval parameters that were hard to train (and whose training probably hadn't even converged) while the latter (EVAL0-9) had <=730 params.

Seeing how much success A0 and lc0 have had despite having to train millions of weights, I guess that adding and tuning pairwise PSTs with <300K values in total (out of which, at most a few hundred would be used per position) could strengthen an A/B engine, which I certainly wouldn't have imagined before the A0 papers. Is anyone brave enough to spend plenty of effort on this idea? Or is Western chess too different from xiangqi for it to ever work?

The approach can be extended to certain triples of pieces, like a certain piece plus both kings as Pawel initially suggested -

I am playing with the idea of indexing piece/square tables by [piece][square][ownKingPosition][enemyKingPosition].

- but that would add even more params, so caution is needed. I've simply brought up an extra data point (the preprint) in support of the general idea of multi-piece PSTs.

[Tony P.]

Also, while we're at it, let me necro HGM's rotated nibbleboard idea from the WB forum as well

I'm still not sure if it's best to store 2, 3 or 4 bits of info per square.

The problem with 4 bits/sq (hence 32 bits per ray) is that the LUT would be too large to fit into RAM, but unlike in 2006, it would be small enough to fit onto an SSD, and it could probably be hashable in RAM, as only a small part of it would be needed in the search from a certain position.

[PK]

Perhaps I will revisit this idea at some point. Additional incentive is what I've done in Rodent IV. It calculates two different, competing piece/square table scores for the entire board, and then does weighted average of them, pulling result towards better of the scores (more so if score difference is bigger). This is of course not as robust as a full-blown neural network, but still a neat way to add some form of second-order non-linear scoring.

[Tony P.]

The Chinese chess paper (section V.B) reports that, in a match between trained EVAL0 versions, the one with tapered eval (which, in that case, interpolated between the opening and the endgame) beat the one without convincingly, with a 62.75% winrate, but of course, the tapering coefficient doesn't have to only depend on the phase of the game, and even further gains seem possible if there are >2 competing scores like in Winter (which currently has 4, as regulated by the kNumClusters constant).

[PK]

Just to be clear, Rodent IV code compares competing piece/square table scores which already take into account game phase. Winter does something else (probably something great).