hgm wrote: ↑Sat Sep 18, 2021 7:58 pm
What Ed descibes is detecting opportunities to capture a King with a sequence of 3 moves (of the same player). What you asked for is detecting opportunities to capture the King with a sequence of 2 moves.
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.
Edit: and yes, what he suggests would happen one node up in the tree, thus is not exactly what I asked for. Yet it might actually help solving the problem.
hgm wrote: ↑Sat Sep 18, 2021 7:58 pm
What Ed descibes is detecting opportunities to capture a King with a sequence of 3 moves (of the same player). What you asked for is detecting opportunities to capture the King with a sequence of 2 moves.
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.
90% of coding is debugging, the other 10% is writing bugs.
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
Thats 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.
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.
oh ok, well that functionality is a defined rule in order to implement frutility pruning.
hgm wrote: ↑Sat Sep 18, 2021 7:58 pm
What Ed descibes is detecting opportunities to capture a King with a sequence of 3 moves (of the same player). What you asked for is detecting opportunities to capture the King with a sequence of 2 moves.
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.
It 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.
R. Tomasi wrote: ↑Sat Sep 18, 2021 8:02 pmMoves or plies?
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.
R. Tomasi wrote: ↑Sat Sep 18, 2021 8:02 pmMoves or plies?
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: ↑Sat Sep 18, 2021 7:58 pm
What Ed descibes is detecting opportunities to capture a King with a sequence of 3 moves (of the same player). What you asked for is detecting opportunities to capture the King with a sequence of 2 moves.
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.
It 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.
[fen]r7/1R3pp1/4p1k1/3pP1Np/2pP4/2P5/5PPP/6K1 b - -[/fen]
As simple as possible.
1. In this position during search the move Kxg5 is already searched and thus alpha has a reliable value.
2. The move Rf8-a8 is evaluated (see diagram) and the eval score is way below alpha and we are trying to reduce the move or prune the tree depending on depth. We check if the move Ra8 might be dangerous and if that's true we don't reduce or prune. And one of the conditions is to detect if the move Ra8 may create a check.
3. A rook can go 4 directions, we try them all. We loop through direction -1, via a table look up conclude that Ra7 never can produce a check, same for squares a6,a5,a4,a3,a2. Arrived on a1 the table produces a true value and arrived here I call an existing routine (I suppose everybody has) that checks if the board situation (WKg1 <> BRa1) produces a check and if so the move Rf8-a8 isn't pruned or reduced while all other rook moves are pruned or reduced.
That's is.
Meanwhile I get new 403 Forbidden errors
90% of coding is debugging, the other 10% is writing bugs.
