Ratings & Comments
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.)
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.
Oh, a silly trivial mistake on my part. Thanks!
So I would suggest a compromise between your quick method and your reliable method. Flag pieces that can capture a piece without moving to its space, and use your reliable method on these while just checking if other pieces can move to the King's space.
I think I managed to even use some acceleration for the pieces that can perform 'locust capture', by avoiding you have to generate all their moves, and just limit it to moves that could potentially hit the King. This would be the move that already delivers check, and the moves that that mutate a square along the path in a way that would allow a slider leg of the locust capture to pass. Which is what was already done for direct captures too.
The issue was that the test for being already in check was done with the King taken off the board, by comparing the destination of capture-capable moves with the King square. But this was tested only on a final leg, and not for a non-final leg, where the capture would be a locust capture, and the piece would move on after it. I now compare the (temporary evacuated) locust square with the king position too, and if it matches make the move go over to the next leg to see if it can be completed. (For an Advancer that would always be possible, but a Long Leaper it might not be.) If the move can be completed, the locust square would be marked as attacked. This will then make the 'check' message appear.
But more importantly, squares on the second leg would also get marked as squares where a check could be discoved. 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 accelerated test would only have noticed that if the second leg of the Checker capture would have added that Checker capture to the moves affected by mutation (= evacuation) of that landing square.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Also (belated) Happy Birthday :)
Thanks! :)
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
The first position in each row is for the non-capture. So if the Cannons are number 12 and 13 in the table, the Cannon x Cannon indications would need to be in the 13th and 14th element of the row. So 12 'nothing special' positions in front of them.
There is no row for empty squares, as empty squares cannot be moved. So you would have to specify this in the 12th and 13th row of the matrix. But it seems you are doing it in the 13th and 14th.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Aand you've rederived these pieces as a back‐formation ;) These are the original (long‐ and short‐, respectively) non‐helical switchback rhinos as proposed by Gilman (and independently by KelvinFox).
Actually never mind, these are two of Gilman's four: Long‐switchback Rhino and Short‐switchback Mirror Rhino. The other two move the same but with the non‐alternating step first.
Note incidentally that Gilman's ‘rhino’ is this one (specifically the sliding version), not the (modified) GA one as popularised by Jean‐Louis (hence why both forms are referred to by that name). The fact that both begin W
‐then‐F
is coïncidence
Also (belated) Happy Birthday :)
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Since this comment is for a page that has not been published yet, you must be signed in to read it.
Rocket, which is square interpretation of Zip on cluster cell in Rocket Chess, which is mentioned earlier, moves as following:
In other words: forward Rook, forward sidemost Zip, backward narrow Electrician.
Otherwise it has a simpler version which is forward Rook, backward Bishop and forward sidemost Nightrider:
can you castle through attacked square if you still have another king
Maybe it is better if I explain what I want to do.
So there are these two pieces (in position 12 and 13):
lightcannon:X:mRcpR:cannon:a4,n4,,a11,n11
heavycannon:Y:pRpafcpR:warmachine:a2,n2,,a13,n13
The rule I want to implement is that heavy cannons cannot jump, be jumped, captured or be captured by other cannons. My captureMatrix looks like this:
captureMatrix=////////////11$$./11$$./
but probably I got it wrong.
Note the heavy cannon is a bit more than a korean cannon is as it can jump two platforms in order capture, but not move.
With the current coloring scheme it is very hard to distinguish occupied squares from empty squares; the pieces blend in too easily with the bright square and arrow colors. I would recomment to decrease the saturation of all the board colors by at least 50%. E.g. by giving the image a 50% (or even 70%) transparency and have a whitish background shine through.
Would it be a good idea to add this to global.css?
I think it would be good to have no background color at all for <tr> elements. I see no legitimate use for it. If it is desirable to see the background color of the page for <table>, <tr> or <td> elements, they could simply be transparent. Then the page background would shine through. If it is desirable to have a color for table cells that is different from the page background, then this should be specified for the <table> element, and the <tr> and <td> cells can be transparent to show that color in every cell. This way it is prevented that background colors of a foreground element would cover/hide non-default changes made in the elements behind it.
I guess that 'inherit' is not a sensible setting for elements like <td> and <tr>, which always have a <table> as (grand-)parent element. Because these would automatically get the color of the parent by being transparent. Inheriting the color just causes problems by eclipsing any background-image of the parenet element; it allows the background-color of the parent to sneak in front of its background-image.
In the I.D. I made the cells transparent by specifying an empty string for lightShade and darkShade. This worked, but I don't know if it is the official method (and thus whether it will always keep working). I now learned that in general (semi-)transparency can be set in HTML by using a notation
rgb(R G B / A%)
where A is the opacity (100 = opaque, 0 = fully transparant). Perhaps I should make the Diagram script recognize the empty string as a color spec for the square shades, and replace it by rgb(0 0 0 / 0%).
I think you have Missed my previous comment here, HG!
I was out of town for the computer-chess tournament in Zundert.
I don't know how to say that the source piece cannot hop to move, to capture, or capture said type. Meaning both ? and $.
I am not sure what you are asking. If you cannot hop to move or capture, you cannot hop at all, right?
$ indicates you can neither hop over, nor capture said type. If you can capture, but not hop, it would be indicated by ^. It is not possible in general to specify multiple effects for the same piece-combination in the captureMatrix, and in most cases this would not be meaningful anyway. (E.g. it makes no sense to specify what you promote to is the capture is forbidden.) The hop ban is special in this respect, as it does not refer to the occupant of the destination square, so that the move can involve 3 piece types. To cover the case of the Korean Cannon I introduced the $ symbol.
I was thinking of splitting the checked function into separate checked-real and checked-potential functions, but as I was looking into which would be which, it looked like there was never any time when it was passed an empty space after the King just moved. In the Pre-Move sections, kpos or Kpos would be updated before calling the function, and in stalemated, it would check whether the King was the moving piece and pass the King's new position if it was. This meant I could reduce the function to this:
def checked anytrue lambda (fn const alias #0 var key var king)
cond isupper space var king (onlylower) (onlyupper)
=movetype CHECK
=king;
Just in case, I ran this code in Ultima as a test:
sub checked king:
my from piece;
local movetype;
set movetype CHECK;
if empty var king:
die "The King space at {#king} is empty.";
endif;
if isupper cond empty var king $moved space var king:
def enemies onlylower;
else:
def enemies onlyupper;
endif;
for (from piece) fn enemies:
if fn const alias #piece #from var king:
return #from;
endif;
next;
return false;
endsub;
def checked sub checked #0;
This code would exit right away with an error message if the subroutine, which was called by the function here, got passed an empty space. I then looked at completed games using the same include file, and they did not exit with the error message. So, I got rid of this code and modified the function, tested Ultima again, and it still worked for both actual checks and for moves that would move the King into check.
With that change made, I ran the speed tests again and got these results:
Elapsed time: 1.0438919067383 seconds
Elapsed time: 0.46452307701111 seconds
Elapsed time: 1.013090133667 seconds
Elapsed time: 0.48957395553589 seconds
Elapsed time: 1.1313791275024 seconds
Elapsed time: 0.49660110473633 seconds
In each pair the subroutine is first, and the function is second, and in each case the function takes less than half the time. In both this case and the previous one, these tests were done on the opening position in Chess, in which the King is not in check, meaning that it checks for check from every enemy piece without exiting early.
25 comments displayed
Permalink to the exact comments currently displayed.
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.
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.
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.