TalkChess.com

Interesting idea, not one that I'd use but it's at least fun to think about. So the basic idea is you search each position in the tables a fixed number of nodes, and then use a simple heuristic to classify the position as w/l/d, then compare that to the real value, and if the search result is right ...

Proving a draw is MUCH harder than proving a win. You have to refute every move by both sides. If there is a win, and if it is simpler than most people expect, it might be possible with a few more years of tech advances to prove it. But if it is a draw, there is no way with currently foreseeable tec...

The basic idea of NNUE is to use an absurdly huge first layer, almost all of the inputs of which are 0, and incremental updates to make that fast. So if you are using a fairly small first layer(and you are) then you are not using the NNUE idea.

alpha-beta can get your average branching factor down to around 6-8 with great move ordering, since it alternates trying all moves at one depth with trying just the one move needed to refute that move at the next depth. And since it only discards moves that are proven to not affect the final score i...

That is some seriously horrific code. And the basic idea(trying to have the network predict a move directly in algebraic notation using three outputs, x, y, and piece type) is pretty terrible also. One part that really sticks out as do-not-copy is where he tried to one-hot encode the column with a=n...

So the TCS way is to look at the complexity of NxN chess. The problem is to solve an arbitrary position in NxN chess by a method that is not exponential in N. But it was shown decades ago that this cannot be done. If we could solve NxN chess with a method that IS exponential in N, that would be an ...

But even 4k3/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQ - 0 1 is not trivial to prove, although looking at a few lines, it looks like it could be done in a day or so. Just a followup on this, I left 1 core of my computer running on this while I did other stuff, and(not too surprisingly) this is proven...

I have wasted a fair amount of cpu time trying to prove that giving queen odds is a forced loss. So what can you prove is a forced loss, Queen + rook, Queen + 2 rooks ? I haven't bothered to search much on more extreme odds. But even 4k3/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQ - 0 1 is not trivial ...

Imagine if you had a million GPUs cooperating in an AND/OR proof search. You could generate 1 million openings from the starting position for which evals of SF, LC0, and Komodo are between -1 and 1 at the leaf nodes. Choose a few at random and try to solve them using this method. If you can solve t...

2) And the risk of hash collisions should only be affected by speed and number of hash table entries, not number of piece types. At least if you do it right. Just have an array of random 64 bit numbers indexed by piece type and location on the board, so as you get more piece types your array gets bi...