Moderator: Ras
Moves or plies? I may have completely missunderstood what Ed suggested: I was thinking of sequences like Ra8 ... Ra1#. Thus preventing the node that is a checkmate from being overlooked.
Not exactly, in diagram 1 the black rook is already on a8 and in diagram 2 the white rook is already on e1. I posted it that way to emphasize it's about one move only, not all moves. It's a kind of fast static nullmove looking for checks.
Well, your loss. I'll keep this gem to myself then. Could have taken your little chess engine to the next level.
oh ok, well that functionality is a defined rule in order to implement frutility pruning.Mergi wrote: ↑Sat Sep 18, 2021 10:05 amThats exactly what he doesnt want to do. He wants to know whether there are even such moves in the first place, rather than generating them or even worse, making them on the board.pedrojdm2021 wrote: ↑Sat Sep 18, 2021 6:43 am you can see there that my trick to known if the move is giving check is just to call InCheck function AFTER the MakeMove
I think the confusion stems from why you would even need such a functionality in the first place. If you are in a node, that would be cut, you would generate all the checking moves, presumably with a special mask or even just a separate generator. If there are no such moves, you simply get back an empty list, and cut the node. This should be already very very fast.
Why don't you want a function that predicts whether there's any move at all to detect checkmates early? Seeing as checking moves are a subset of all moves, finding out whethere there's any move might be easier than finding out whether there's a very special kind of move, a checking move, right? Yet nobody, at least to my knowledge, is doing checkmate verification before the move loop. If you can predict that there is a move, you might as well generate it.
Even if there's some Emanuels-smart-move-prediction algorithm, that is yet to be discovered, this really seems like a pointless thing to attempt to do.
It is not entirely clear to me at which time the move is judged. Is the following understanding correct?
Moves of a specified players are always plies. But three moves of that player in a row is not the same as three ply, as a three-ply search would have the second ply made by the opponent. So it is actually a 5-ply search, where the opponent only plays null moves.
Ok, I think we actually mean the same: What I thought Ed's idea to be, was that Ed's routine would influence the pruning decision for the node that is 2 ply down the tree, since it detects if there is a new check 3 ply down (which corresponds to capturing the king 5 ply down). So the routine would have to be called at the grandparent of the node that is to be pruned/not pruned.hgm wrote: ↑Sun Sep 19, 2021 12:04 pmMoves of a specified players are always plies. But three moves of that player in a row is not the same as three ply, as a three-ply search would have the second ply made by the opponent. So it is actually a 5-ply search, where the opponent only plays null moves.
hgm wrote: ↑Sun Sep 19, 2021 12:01 pmIt is not entirely clear to me at which time the move is judged. Is the following understanding correct?
* In the position of the diagram, you generate all moves, including Ra8.
* All these moves are made
* Then it is tested whether the moved piece could capture the King in two moves (the first possibly by discovering it).
For Ra8 this is the case (Ra8-a1, Ra1xg1). For other moves (or at least non-captures), you immediately return a fail low, effectively pruning it retro-actively. (Because the eval remains too much below alpha?)
* With the Rook on a8 you now generate and search all moves of white.
* After most of those you search at least Ra8.
