Check out Glinski's Hexagonal Chess, our featured variant for May, 2024.

Enter Your Reply

The Comment You're Replying To

Jean-Louis Cazaux wrote on Sat, Feb 17 01:02 PM UTC:

@HG: while playing some of my games, for example this log:

https://www.chessvariants.com/play/pbm/play.php?game=Bigorra&log=arx-cvgameroom-2023-268-980

At every click, to open the game, then when moving a piece, then when confirming the move, etc., the screen displays a page with a lot of lines as the ones I copy and paste here below.

That screen disapears quickly with apparently no consequence, so it is not a major problem, but it is disturbing. This phenomena has started 1 week ago or so. It happens also on other logs where I'm playing. It seems to be related to the locust-stuff.

I don't understand what has been changed.

Please report any bugs or errors to H.G. Muller k5k7#locustqsr00 i12i10#locustqsr00 l5l7#locustqsr00 i13i11#locustqsr00 k4k6#locustqsr00 j12j10#locustqsr00 j5j7#locustqsr00 h12h10#locustqsr00 i5i7#locustqsr00 i10i8#locustqsr00 m5m7#locustqsr00 k12k10#locustqsr00 m4m6#locustqsr00 g12g10#locustqsr00 h10h8#locustqsr00 h5h7#locustqsr00 f12f10#locustqsr00 f13f11#locustqsr00 l12l10#locustqsr00 i9i7#locustqsr00 g10g8#locustqsr00 h13h11#locustqsr00 d5d7#locustqsr00 d12d10#locustqsr00 d4d6#locustqsr00 e12e10#locustqsr00 e5e7#locustqsr00 e10e8#locustqsr00 m12m10#locustqsr00 n5n7#locustqsr00 n12n10#locustqsr00 f5f7#locustqsr00 c12c10#locustqsr00 g5g7#locustqsr00 g6g8#locustqsr00 l10l8#locustqsr00 c5c7#locustqsr00 b12b10#locustqsr00 b10b8#locustqsr00 n10n8#locustqsr00 p5p7#locustqsr00 f6f8#locustqsr00 o5o7#locustqsr00 m7m9#locustqsr00 a12a10#locustqsr00 h7h9#locustqsr00 h11h9#locustqsr00 m13m11#locustqsr00 c10c8#locustqsr00 a10a8#locustqsr00 o6o8#locustqsr00 p12p10#locustqsr00 j14j12#locustqsr00 k7k9#locustqsr00 k13k11#locustqsr00 h4h6#locustqsr00 j3j5#locustqsr00 i8l11#locustqsr00 i8l5#locustqsr00 i8f5#locustqsr00 i8f11#locustqsr00 i8i11#locustqsr00 i8l8#locustqsr00 i8i5#locustqsr00 i8f8#locustqsr00 i8j11#locustqsr00 i8l9#locustqsr00 i8h5#locustqsr00 i8f9#locustqsr00 i8h11#locustqsr00 i8k11#locustqsr00 i8l10#locustqsr00 i8k5#locustqsr00 i8g5#locustqsr00 i8f10#locustqsr00 i8g11#locustqsr00 k8k9#locustqsr00 k8l9#locustqsr00 m8m9#locustqsr00 m8n9#locustqsr00 m8l9#locustqsr00 c7c8#locustqsr00 c7c9#locustqsr00 e7d7#locustqsr00 f7f8#locustqsr00 f7f9#locustqsr00 i7i6#locustqsr00 i7h7#locustqsr00 i7i9#locustqsr00 i7k7#locustqsr00 i7i5#locustqsr00 i7g7#locustqsr00 j7j8#locustqsr00 j7j9#locustqsr00 l7l8#locustqsr00 n7n8#locustqsr00 o7o8#locustqsr00 o7o9#locustqsr00 d6e9#locustqsr00 d6g7#locustqsr00 d6g5#locustqsr00 d6a7#locustqsr00 d6c9#locustqsr00 e6f5#locustqsr00 e6d7#locustqsr00 e6f4#locustqsr00 e6d8#locustqsr00 e6d9#locustqsr00 e6d10#locustqsr00 f6g6#locustqsr00 h6h7#locustqsr00 h6i6#locustqsr00 h6g6#locustqsr00 h6h8#locustqsr00 k6k7#locustqsr00 k6j6#locustqsr00 m6p9#locustqsr00 m6p3#locustqsr00 m6j3#locustqsr00 m6j9#locustqsr00 m6m9#locustqsr00 m6m3#locustqsr00 m6j6#locustqsr00 m6m7#locustqsr00 p6p7#locustqsr00 p6p8#locustqsr00 a5a6#locustqsr00 a5a7#locustqsr00 c5a3#locustqsr00 c5a7#locustqsr00 d5f4#locustqsr00 j5j6#locustqsr00 j5k5#locustqsr00 j5k4#locustqsr00 j5j4#locustqsr00 j5i5#locustqsr00 j5i6#locustqsr00 m5o6#locustqsr00 m5o4#locustqsr00 m5n3#locustqsr00 m5l3#locustqsr00 m5k4#locustqsr00 n5o8#locustqsr00 n5o2#locustqsr00 n5k4#locustqsr00 o5o6#locustqsr00 o5p5#locustqsr00 b4b5#locustqsr00 b4a4#locustqsr00 c4f1#locustqsr00 c4f4#locustqsr00 c4c1#locustqsr00 d4f5#locustqsr00 d4c2#locustqsr00 d4b5#locustqsr00 d4c6#locustqsr00 d4g5#locustqsr00 d4c1#locustqsr00 d4a3#locustqsr00 d4g6#locustqsr00 d4f1#locustqsr00 d4a6#locustqsr00 d4b7#locustqsr00 i4i5#locustqsr00 i4j4#locustqsr00 i4h4#locustqsr00 i4i6#locustqsr00 m4n3#locustqsr00 m4l3#locustqsr00 m4l5#locustqsr00 m4n2#locustqsr00 m4l2#locustqsr00 n4k7#locustqsr00 n4k4#locustqsr00 p4m1#locustqsr00 p4m7#locustqsr00 p4p7#locustqsr00 p4p1#locustqsr00 p4p5#locustqsr00 b3b2#locustqsr00 b3a3#locustqsr00 c3d2#locustqsr00 c3b2#locustqsr00 c3a1#locustqsr00 d3e4#locustqsr00 d3f5#locustqsr00 d3g6#locustqsr00 d3h7#locustqsr00 d3c2#locustqsr00 e3f5#locustqsr00 e3g4#locustqsr00 e3f1#locustqsr00 e3d1#locustqsr00 e3c2#locustqsr00 e3g5#locustqsr00 e3c1#locustqsr00 e3e5#locustqsr00 f3f4#locustqsr00 f3g5#locustqsr00 f3e5#locustqsr00 g3g4#locustqsr00 g3h4#locustqsr00 g3f4#locustqsr00 g3g5#locustqsr00 h3h4#locustqsr00 h3h5#locustqsr00 h3j3#locustqsr00 i3k4#locustqsr00 i3g4#locustqsr00 i3h5#locustqsr00 i3k5#locustqsr00 i3g5#locustqsr00 i3i5#locustqsr00 i3k3#locustqsr00 i3i1#locustqsr00 i3i6#locustqsr00 i3l3#locustqsr00 i3j6#locustqsr00 i3l4#locustqsr00 i3l2#locustqsr00 i3f4#locustqsr00 i3l5#locustqsr00 i3f1#locustqsr00 i3f5#locustqsr00 i3g6#locustqsr00 o3o4#locustqsr00 o3p3#locustqsr00 o3o2#locustqsr00 o3n3#locustqsr00 o3m3#locustqsr00 o3l3#locustqsr00 o3k3#locustqsr00 o3j3#locustqsr00 a2a3#locustqsr00 a2a4#locustqsr00 a2b2#locustqsr00 a2c2#locustqsr00 a2d2#locustqsr00 a2a1#locustqsr00 a2a8#locustqsr00 e2d2#locustqsr00 e2c2#locustqsr00 e2b2#locustqsr00 e2f1#locustqsr00 e2d1#locustqsr00 f2g4#locustqsr00 f2d1#locustqsr00 f2e4#locustqsr00 g2f1#locustqsr00 g2h4#locustqsr00 g2i1#locustqsr00 g2f4#locustqsr00 g2e4#locustqsr00 g2g4#locustqsr00 h2i1#locustqsr00 h2j4#locustqsr00 h2f4#locustqsr00 h2h4#locustqsr00 h2j3#locustqsr00 h2f1#locustqsr00 h2g4#locustqsr00 i2j3#locustqsr00 i2k4#locustqsr00 i2l5#locustqsr00 i2i1#locustqsr00 j2k3#locustqsr00 j2i1#locustqsr00 j2l3#locustqsr00 j2m3#locustqsr00 j2n3#locustqsr00 j2k4#locustqsr00 j2k5#locustqsr00 k2k3#locustqsr00 k2k4#locustqsr00 k2k5#locustqsr00 k2l2#locustqsr00 k2l4#locustqsr00 k2m3#locustqsr00 k2m1#locustqsr00 k2i1#locustqsr00 k2j4#locustqsr00 m2n3#locustqsr00 m2o4#locustqsr00 m2p5#locustqsr00 m2l3#locustqsr00 m2k4#locustqsr00 p2p3#locustqsr00 p2p1#locustqsr00 p2o2#locustqsr00 p2n2#locustqsr00 b1b2#locustqsr00 b1c2#locustqsr00 b1c1#locustqsr00 b1a1#locustqsr00 b1d1#locustqsr00 e1f1#locustqsr00 e1d1#locustqsr00 e1d2#locustqsr00 e1c2#locustqsr00 g1f1#locustqsr00 h1i1#locustqsr00 j1i1#locustqsr00 j1l3#locustqsr00 j1j3#locustqsr00 j1g4#locustqsr00

Edit Form

Comment on the page Game Courier Logs

Name or UserID: Password: if signing in with UserIDRating: Comment or question:
Format:

Conduct Guidelines

This is a Chess variants website, not a general forum.: Please limit your comments to Chess variants or the operation of this site.
Keep this website a safe space for Chess variant hobbyists of all stripes.: Because we want people to feel comfortable here no matter what their political or religious beliefs might be, we ask you to avoid discussing politics, religion, or other controversial subjects here. No matter how passionately you feel about any of these subjects, just take it someplace else.

Quick Markdown Guide

By default, new comments may be entered as Markdown, simple markup syntax designed to be readable and not look like markup. Comments stored as Markdown will be converted to HTML by Parsedown before displaying them. This follows the Github Flavored Markdown Spec with support for Markdown Extra. For a good overview of Markdown in general, check out the Markdown Guide. Here is a quick comparison of some commonly used Markdown with the rendered result:

# Top level header: `<H1>`

> Block quote 
>
> Second paragraph in block quote

First Paragraph of response. *Italics*, **bold**, and ***bold italics***.

Second Paragraph after blank line. Here is some <U>HTML code</U> mixed in with the Markdown, and here is the same `<U>HTML code</U>` enclosed by backticks.

## Secondary Header: `<H2>`

* Unordered list item
* Second unordered list item
+ New unordered list
    * Nested list item
- An URL by itself:
    + https://www.chessvariants.com
- A text link:
    - [The Chess Variant Pages](https://www.chessvariants.com)

### Third Level header `<H3>`
	
1. An ordered list item.
1. A second ordered list item with the same number.
2. A third ordered list item.

~~~
Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.
~~~

![Alt text for a graphic image](/graphics.dir/cvp-logo-draft8.png)

A definition list
: A list of terms, each with one or more definitions following it.
: An HTML construct using the tags `<DL>`, `<DT>` and `<DD>`.

A term
: Its definition after a colon.
: A second definition.
: A third definition.

Another term following a blank line
: The definition of that term.

Top level header: `<H1>`

Block quote

Second paragraph in block quote

First Paragraph of response. Italics, bold, and bold italics.

Second Paragraph after blank line. Here is some HTML code mixed in with the Markdown, and here is the same <U>HTML code</U> enclosed by backticks.

Secondary Header: `<H2>`

Unordered list item
Second unordered list item

New unordered list
- Nested list item

An URL by itself:
- https://www.chessvariants.com
A text link:
- The Chess Variant Pages

Third Level header `<H3>`

An ordered list item.
A second ordered list item with the same number.
A third ordered list item.

Here is some preformatted text.
  This line begins with some indentation.
    This begins with even more indentation.
And this line has no indentation.

A definition list: A list of terms, each with one or more definitions following it.; An HTML construct using the tags <DL>, <DT> and <DD>.
A term: Its definition after a colon.; A second definition.; A third definition.
Another term following a blank line: The definition of that term.

Credits

Author: Fergus Duniho.

Comments

Game Courier Logs. View the logs of games played on Game Courier.

🕸📝Fergus Duniho wrote on Tue, May 14 06:51 PM UTC in reply to H. G. Muller from 07:19 AM:

Marking of attacked squares to weed out illegal King moves is just one of the two things the accelerated check test does. The other thing is that it tabulates for each board square which (attempted) sliding moves visit it.

It's not the same thing that you're doing, but I have now made a quicker version of stalemated called stalemated-quick, which does some preprocessing to reduce the work involved in checking for check. It starts by creating an array of the King's location and each space it may move to, and for each location in this array, it makes an array of every location with an enemy piece that has it in its range. The code looks like this:

// Build threat lists
set krange merge fn join const alias space #kingpos "-Range" #kingpos #kingpos;
set threats ();
for to #krange:
  set threats.{#to} ();
next;
for (from piece) fn #enemies:
  set in intersection var krange fn join const alias var piece "-Range" var from;
  for to #in:
    push threats.{#to} #from;
  next;
next;

So it creates multiple elements of an array called threats, each of which is an array of the enemy pieces that include that space in its full range of movement. At the start of Chess, threats.d2 and threats.d1 both have one element set to d8, and the others (elements e1, e2, f1, and f2 of threats) are empty.

To check for check, it first assumes a value of false, and it tries out the move only if there are pieces potentially threatening the space the King is on. That move looks like this:

set checkpos cond == #from #kingpos #to #kingpos;
set checked false;
if count elem var checkpos threats:
  move #from #to;
  set checked fn threatened #checkpos;
  restore;
endif;

Instead of using the checked function, it used the threatened function, which looks like this:

def threatened anytrue lambda (fn const alias space #0 #0 var king) 
elem var king threats 
=movetype CHECK 
=king;

This function expects threats to be populated with appropriate values. So it can't be used everywhere checked can.

In tests with Chess, everything seems to be working. After making sure it worked, I did some speed tests comparing 100 calls to stalemated with 100 calls to stalemated-quick. In each pair, stalemated is first, and stalemated-quick is second. The results show that stalemated-quick is normally quicker.

Elapsed time: 4.7686970233917 seconds

Elapsed time: 2.8460500240326 seconds

Elapsed time: 4.8747198581696 seconds

Elapsed time: 3.0506091117859 seconds

Elapsed time: 4.4713160991669 seconds

Elapsed time: 2.9584100246429 seconds

H. G. Muller wrote on Tue, May 14 07:19 AM UTC in reply to Fergus Duniho from 02:09 AM:

5. It checks whether the King is in check by checking whether any enemy piece can move to the King's space. As an optimization, it returns true as soon as it finds one check.

The efficiency of your algorithm depends on whether there is a fast method to answer the question "does the piece at square A attack square B", which then can be combined to a function "IsSquareAttacked" by looping over all pieces A. But for complex multi-leg moves (pieces that turn corners, or jump over others, or do not end their move at the square they attack) it is hard to find a shortcut even if you are writing dedicated code for it. Often the best way is to just generate all moves of the piece at A, and for each of those test if it happens to hit B. For simple sliders and leapers it would be possible to immediately exclude they are attacking B based on the (x,y) coordinates of the leap from B to A (e.g. x*y!=0 for a Rook), or even tabulate in which direction you would have to move to arrive at B (and then test whether this path is unobstructed).

I could of course classify pieces (or even their individual moves) as simple or complex, and use a fast "does A attack B" function for leaps and straight slides, and only generate the complex moves of all enemy pieces to test whether these hit B. Typically only a small fraction of the pieces will have complex moves, and then this could be competitive.

This optimization might be helpful when not using piece functions, but one thing about it concerns me. While it might be helpful in determining whether a move by the King would be into check, I'm not sure it will work for revealed checks. It is because of the possibility of revealed checks that my code checks for check for the position resulting from every single pseudo-legal move it finds.

Marking of attacked squares to weed out illegal King moves is just one of the two things the accelerated check test does. The other thing is that it tabulates for each board square which (attempted) sliding moves visit it. If such a move did not hit B before, it cannot hit B after a move that would not mutate at least one of the squares that the move visited. E.g. if a Cannon is looking at the King directly it would not check, but during move generation the first leg of the move in the direction of the King would have been attempted, and perhaps even succeeded by capturing something that was behind the King. But whether it succeeded or not, all the squares between Cannon and King would get this Cannon move added to the list of moves that visit them.

If the move to be tested for legality would land on an empty square between Cannon and King, it would see in the constructed table that there was a Cannon that had a move that went over the destination square, and thus will be affected. It will then retry that move of that Cannon, to test whether it hits the King in the new position. Likewise, it would see whether (say) a Bishop had been attacking its origin, and then rerun that Bishop move to test whether it hits the King. This takes care of discovered slides and hopper activation. Moves of other pieces, as well as other moves of these same pieces would not have to be tried; these were not hitting the King before, none of the squares they visited was mutated, so they won't hit the King now.

This is actually the most robust part of the algorithm, which would even work in case of multiple absolute royals: moves that were not checking before cannot check after a move that did not mutate any squares in their path. (But if there are Immobilizers...)

In general the algoritm is very fast: for each move with a royal you test whether the destination is marked as attacked, and for moves with non-royal pieces you only have to rerun the opponent sliding moves that were tabulated as hitting origin or destination (and occasionally other squares that were mutated). And on average there are fewer than 1 enemy sliding moves (i.e. moves that could potentially have continued if the occupancy of the square had been different) to a square, in a typical variant. So in many cases a pseudo-legal move can be accepted as legal by just concluding that the mover was not royal, and the origin and destination of it were not visited by any opponent move. When already in check, it always reruns the move that was delivering that check, as the first test. (Most moves would not resolve the check, and these can then be discarded without further testing.)

Anyway, it is possible to configure the preset to not use the accelerated test, and for a not-too-lage variant (8x8 or 10x10) this will probably work fine.

🕸📝Fergus Duniho wrote on Tue, May 14 02:09 AM UTC in reply to H. G. Muller from Mon May 13 08:30 PM:

That would indeed be an alternative: do a full king-capture test after every King move. But it would be more expensive, as a King usually has several moves.

It's more than that. I do a full king-capture test for every pseudo-legal move by every piece that can move. My code works like this.

It goes through every piece from the side that can move.
For each piece on the side that can move, it calculates the spaces within its range of movement. This is an optimization to keep it from checking for legal moves to every position on the board.
For each space within a piece's range of movement, it checks whether the piece has a pseudo-legal move there.
For each pseudo-legal move, it tries the position and checks whether it places the King in check.
It checks whether the King is in check by checking whether any enemy piece can move to the King's space. As an optimization, it returns true as soon as it finds one check.
It checks whether a piece may move to the King's space by calling its function for the move from its location to the King's space.
Divergent pieces are handled by writing them to behave differently when the movetype variable is set to CHECK. In the following example, the function for the White_Pawn first checks some conditions any Pawn move must meet, then handles capturing, then continues to handle non-capturing and en passant moves only if movetype is not CHECK.

def White_Pawn
remove var ep
and < rankname #1 var bpr
and < rankname var ep rankname #1
and == filename var ep filename #1
and checkleap #0 #1 1 1
and var ep
or and checkride #0 #1 0 1 == rankname #0 var wpr
or checkleap #0 #1 0 1
and empty #1
and != var movetype CHECK
or and islower space #1 checkleap #0 #1 1 1
and any onboard where #1 0 1 == var movetype CHECK count var wprom
and <= distance #0 #1 var fps
and > rank #1 rank #0;

Pieces with non-displacement captures are handled by writing two different functions for them and using the value of movetype to call the correct function.

So you would have to do enemy move generation several times.

Since my code uses piece functions, this is not a big problem. In tests I ran yesterday, my checked function ran 1000 times in under half a second, and the checked subroutine got called 1000 times in close to a second, and this was on a position in which the King was not in check, which meant it never broke out early. Since your code does not use piece functions, it may handle the evaluation of moves more slowly, which will also cause it to evaluate check more slowly.

Testing whether a destination contains the King is not any more expensive than marking the destination. And to do it, you only need to geenrate all enemy moves once.

This optimization might be helpful when not using piece functions, but one thing about it concerns me. While it might be helpful in determining whether a move by the King would be into check, I'm not sure it will work for revealed checks. It is because of the possibility of revealed checks that my code checks for check for the position resulting from every single pseudo-legal move it finds.

I suppose one optimization that could be made if it were needed would be to identify the pieces that might possibly check the King at its current location, then limit the test for whether a move by another piece places the King in check to those pieces. This could be done by making a short list of every enemy piece whose range of movement contains the King's location and having the checked function use it instead of onlyupper or onlylower. If this list were empty, it could even skip the step of trying out a pseudo-legal move and testing whether it places the King in check.

However, this might not work for non-displacement captures in which the capture occurs outside the piece's range of movement, such as the Coordinator capture in Ultima. So, I have to balance efficiency with the work a programmer has to make to use a piece in a game. The brute force method I use helps reduce the work the programmer has to do to make different kinds of pieces work with it.

H. G. Muller wrote on Mon, May 13 08:30 PM UTC in reply to Fergus Duniho from 07:35 PM:

Why would you take the King off the board for this?

The purpose of the accelerated check test is not only to determine whether the King is in check in the current position, but also to greatly facilitate testing whether the King would get exposed by any of the moves. One contribution to this is to mark every square where the King itself cannot go. The King is taken off to prevent it would block enemy slider moves (or lame leaps), creating the illusion that it would be safe to "step into his own shadow".

The test is NOT done by only processing all pseudo-legal moves. Because that would not reveal which pieces are protected (and thus cannot be captured by the King). For the purpose of knowing where the King could go the move generator should basically work under the fiction that all destinations contain the enemy King. That applies to empty squares as well friendly pieces; these will be marked as inaccessible to the King when the move hitting those is a move that can capture. Even when it cannot capture what is actually there.

The code I use avoids this by trying each pseudo-legal move and checking whether any piece in the new position is checking the King.

That would indeed be an alternative: do a full king-capture test after every King move. But it would be more expensive, as a King usually has several moves. So you would have to do enemy move generation several times. (And who knows how mobile a royal piece can be, in a chess variant?) Testing whether a destination contains the King is not any more expensive than marking the destination. And to do it, you only need to geenrate all enemy moves once. Then for each King moves only have to test whether the destination is marked. And to know whether you are in check it would just have to test whether the square the King is currently on is marked.

But the fiction that every square where you are allowed to capture contains a King should also be applied to locust captures. And this wasn't done.

The accelerated check test would not work in variants where there are multiple absolute royals. (Extinction royaly is no problem; there it just skips the check test completely if there still is more than one royal.)

🕸📝Fergus Duniho wrote on Mon, May 13 07:35 PM UTC in reply to H. G. Muller from 05:54 PM:

The issue was that the test for being already in check was done with the King taken off the board

Why would you take the King off the board for this? Couldn't this cause false positives and false negatives from divergent pieces like Pawns or Cannons?

This was a bug that did not yet express itself. A Checker diagonally adjacent to the enemy King would not deliver check if a friendly piece was immediately behind that King, blocking the landing square. But that blocking piece would then essentially be pinned, and its moves should not be highlighted.

The code I use avoids this by trying each pseudo-legal move and checking whether any piece in the new position is checking the King.

Number of ratings: 29, Average rating: Excellent, Number of comments: 728

List all comments and ratings for this item.

Add a comment or rating for this item.

The Chess Variant Pages is an amateur, hobbyist website that has been run by volunteers since it was founded in 1995. It focuses on documenting games based on, related to, or similar enough to Chess and on letting you play many of them.

Who What When Where Why Which How

Privacy

Operating expenses are covered through advertising and donations. Help out by making a PayPal donation or by shopping with these affiliate links:

https://www.chessvariants.org/index/editcomment.php
First Created: Wednesday, January 16th, 2002
Last Modified: Tuesday, September 9th, 2003
File Timestamp: Tue, 05 Mar 2024 01:07:52 +0000
[info] [links] [edit]

Enter Your Reply

Top level header: <H1>

Secondary Header: <H2>

Third Level header <H3>

Top level header: `<H1>`

Secondary Header: `<H2>`

Third Level header `<H3>`