Comments/Ratings for a Single Item

Then I would like to try again to draw the attention of the editors to this version, now that the description has been corrected (thanks Ben) - in the hope that publication is now possible.

I wish all of you a happy 2024.

Unfortunately, it is not possible for me to convert 'Conquer II' into an interactive diagram, so I have to rely on the help of experienced programmers. The conversion in GC seems to be successful and works in the test games so far.

It is very much possible. You just don't know how to do so (see this page for details). The Conquer II Pawn can be described as fWncD or fWfafcW.

I think the part that Gerd's talking about is how, when a piece is captured, it's deposited where the capturing piece started (easy, with a u) of the capturing piece's color (harder).

It is very much possible. You just don't know how to do so (see this page for details). The Conquer II Pawn can be described as fWncD or fWfafcW.

Thanks for the tip, I am familiar with the page. It is also clear that the u modifier must be used here. The problem is that the captured piece should take on the colour of the capturing party and, according to H.G., this is not possible without additional programming. That's my hurdle. The Betza notation for the pawn is not the problem.

This is quite the novel idea...

Also, there is already a JavaScript function to do this, from the Interactive Diagram on the Conquer The Opponent's Army page. No u modifier required.

function conquerTinker(m) { var v = board[m[3]][m[2]]; if(v & 511) m[4] = m[0], m[5] = m[1], m[-2]++, m[-5] = v ^ 1024; return 0; }

Indeed, you can simply copy this custom addition to the Diagram script and include it on the page where you have a Diagram that you want to do the same.

Caveat is that it is called 'conquerTinker' because the Diagram to which it belonged hade satellite=conquer amongst its definitions. If you want to use it with a Diagram that has satellite=xxx instead, you should call it xxxTinker. (This so that when there are multiple Diagrams on one page, each can know whether the function should be used by them, or ignored.)

There's another caveat as well - the function's current form doesn't work very well with the AI. As soon as the AI gets to around 6 moves it just stops functioning.

There's another caveat as well - the function's current form doesn't work very well with the AI. As soon as the AI gets to around 6 moves it just stops functioning.

This could be a general problem of the AI, in particular inability to handle a variant with these rules, which the function enables. The AI normally always considers recapture to the destination of the preceding move, in quiescence search. But the recruiting of the captured piece creates the possibility that such capture sequences continue indefinitely, with infinite recursion (and hence crash of the script) as a consequence.

There's another caveat as well - the function's current form doesn't work very well with the AI. As soon as the AI gets to around 6 moves it just stops functioning.

H.G. has created an Interactive Diagram for the basic version 'Conquer the opponent's army'. For this diagram it is known that the AI cannot handle perpetual recaptures because there is no counter for such recaptures in the diagram.

With 'Conquer II' I tried to minimize the perpetual recaptures by changing the pawn move. As far as I know, there is no interactive diagram for Conquer II. It is possible that even such a diagram will reach its limits at some point, as perpetual recaptures cannot be excluded. However, this only happens if the AI is playing against itself. With a little human skill, constant repetitions can be avoided.

Perhaps one more note:
The playability of Conquer does not depend on the AI, which reaches its limits in terms of programming, but on how players deal with perpetual recaptures, if they still occur in Conquer II. The games on GC have not shown any problems so far.

In this respect, it would be nice if there were an interactive diagram for Conquer II. This would show whether the AI copes better with this version.

The author, Gerd Degens, has updated this page.

I vaguely recall that at one point I had solved this problem of perpetual recapture in the AI. But it seems we somehow suffered a regression in the Diagram script; a few weeks ago I also noticed that it was no longer displaying the Fire Dragon in MinJiku Shogi, because it added a .png suffix on a file that already has a .gif suffix. And I am absolutely sure it did display that before. But the code for suppressing duplicat suffix had disappeared.

As for the conquer problem; I believe I solved that by not considering a move that came from the same square as two ply earlier a recapture that should always be searched, but rather as a draw indication. But code for that seems no longer to be there either.

That sounds promising. If something has gone missing, it doesn't mean that it can no longer be found. Perhaps you can shed some light on the black box. It would certainly help others, not just me.

The question is, why did the AI drop out in this constellation? It has nothing to do with permanent recaptures - or does it?

I'm not sure how a change to the Pawn move will make the game less drawish. Regardless, the page is good enough to be approved.

As for the conquer problem; I believe I solved that by not considering a move that came from the same square as two ply earlier a recapture that should always be searched, but rather as a draw indication. But code for that seems no longer to be there either.

@H.G.
It's a pity that the code is no longer available. On the other hand, such perpetual recaptures occur more frequently and earlier in the conquer rule, so that a draw decision would come too early. 

Wouldn't it be better if, instead of a draw announcement, a move that was already made two moves earlier was treated as no longer executable? If nothing other than a repetition is possible, this would mean a draw. Otherwise the game could continue normally without perpetual recapture.

Well, you can wish for something without knowing what effort is involved. I apologise for that. And you can certainly argue about whether the conquer rule is an enrichment. In any case, it leads to differentiated strategic considerations and that is at least something.

That's why I'd like to ask you whether you'd like to deal with this topic again? It would certainly enrich the diagram script. :)

Repetition is a weak spot of the ID anyway; it does not really keep record of the entire game history as a list of 'position signatures' with which it could easily compare the current position. It is aware of the two last-played half-moves, though, and uses those to determine which natural continuations it should still search near the end of its search tree. What it does now is give a slight penalty for moving the same piece as two half-moves earlier, and reduce positive scores by a factor 50% if such a move goes also back to the square it came from, and the earlier one was't a capture. (Even though this might not cause a repetition, it would allow the opponent to reach one if he wants too, and should thus be considered a draw offer.)

In the normal case the shortest repeat loop has 4 half-moves, and requires moving pieces back and forth. So this is what the ID tries to detect in the way described above. In the conquer case repeats can already occur after 2 half-moves, and are brought about by doing the same move instead of the reverse one. So this escapes detection, and fatally interferes with its search strategy to always search moves that recapture to the same square. (Which can go on forever, and then crashes the program.)

Note that the ID never announces a draw by repetition. It only uses the information during its search, to make it aware that certain sequences of moves will not make any progress, and would not be able to convert any advantage that it thinks it has into a win. So that the side that is ahead would avoid these sequences, even if they are the only ones that preserve the advantage it imagines it has. E.g. if you are a Queen ahead, but can only escape perpetual check by sacrificing a Rook, it should not prefer the perpetual just to hang on to the Rook. OTOH, if it is a Rook ahead, and can only escape the perpetual by sacrificing a Queen, it would be preferable to opt for the perpetual; the alternative would likely make you lose. If the repetion would have been forbidden, rather than discouraged by giving it a draw score, it would have no choice but sacrificing the Queen, and lose. So this is not a good idea, unless the rules really are such that repeats are forbidden.

(Which can go on forever, and then crashes the program.)

That's it; whenever I try to apply the conquer mechanism to other variants, the programme aborts after a few moves and the possibility of testing the variant is lost.

...unless the rules really are such that repeats are forbidden.

This is exactly the case with the conquer rule - repeats are forbidden.  That's precisely the crucial question of how this can be implemented in the programme. If I understand or interpret you correctly, this seems to be impossible or only possible with disproportionate effort and you don't really want to deal with it.

Indeed, at this stage we are still far from being able to handle this. The first step would be to equip the AI with true repetition detection, instead of merely discouraging immediate back-and-forth moving for the side that is ahead. After that we can introduce a parameter to control the game result in case of a repetion (draw, loss for the repeater, loss for the checker, ...)

It should be possible to prevent the AI from crashing by 'perpetual recapture' already by simpler means, though. The idea for always allowing this was that sooner or later you would run out of pieces to capture to a given square. But when you capture from the same square as two half-moves before, this might not be the case, as obviously the capturing piece got somehow replaced. So such repeat captures should be exempted from the 'free recapture' rule.

Problem is that it might not always be the previous move. I can imagine positions where each player has two Rooks attacking a square with a Queen, and then alternately capture from the one square or the other. So I suppose I should consider any move that unloads something as suspect, as it violates the assumption that the capture decreases the board population, so that you must sooner or later run out of those. The question is whether not always searching such recaptures would not unduly weaken the AI, though. But anything is of course better than crashing it.

Thank you, that sounds good!

I guess a less restrictive limitation on the search could still always allow capture to the same square of a higher valued piece by a lower; this must always become impossible at some point, even when the captured pieces somehow regenerate.

I now made a slight modification in the Diagram's AI (of betzaNew.js): the condition under which a move is always searched is changed from total gain > value of capturer (which in conquer could go on for ever, with a crash as result) to one where this only holds for moves that do not unload anything, and that moves that do unload something are only searched if they capture a piece of a type higher than their own. (This assumes pieces in the table are sorted by increasing value.) This thus discards the gain from the recruitment; in the old way RxR would gain you two Rooks, and would qualify; now it no longer qualifies, as R=R. It would still always search RxQ, but then two half-moves later not the reverse QxR, even though in the old way 2R might be more valuable than Q.

I hope this solves the problems with crashing in Conquer. (After refreshing your browser cache.) If not, let me know.

I hope this solves the problems with crashing in Conquer. (After refreshing your browser cache.) If not, let me know.

I have refreshed the browser cache, but it seems that loops still occur, as the two examples show: