Comments/Ratings for a Single Item

[R?uW-cW-bpafW]

You are mixing XBetza with bracket notation. You cannot do that; a in bracket notation would mean 'all directions', not continuation. You should have written [R?uW-cW-bpW-fW].

But your original [R?ufW-cfW-bD]  is wrong in the first place. It specifies an unload on the start square of two consecutive W steps, and then a D step back. Which would end up on the same square as the unload. What you really want after the Rook move is step to the unload square (fmW), from there swap with the enemy piece (fucW) and step two back (bD). That is [R?W-ucW-bD]. (But note that this makes the attarction of the enemy piece optional; it could stop after R even if there is an enemy piece two steps further.) The D step would have to be split up in XBetza, and not being a 2nd leg the bracket preprocessor won't do that automatically. But it probably would handle [R?W-ucW-bpW-W] correctly.

This would indeed be hard. One way I could see it done was introduce a special symbol as repeat limiter similar to what i does for slider continuation legs, and thus means "as many repetitions as there were in the previous parenthesized group". Suppose that symbol is $, you could write [(mpW-)pW-(mpW-)$cW]. It is a sort of orthogonal Equihopper.

I like this idea, and the choice of symbol. I can see it being useful for a number of different possibilities (like maybe a bent or hopping rifle capture).

OK, so the bD should've been bpaW (or bpafW), and I should've realized that. Grr.

But now I've tried [R?mW-ucW-bpafW] and [R?uW-cW-bpafW] and various other combinations thereof (both with and without the f), and I still don't get the desired effect.

This would indeed be hard. One way I could see it done was introduce a special symbol as repeat limiter similar to what i does for slider continuation legs, and thus means "as many repetitions as there were in the previous parenthesized group". Suppose that symbol is $, you could write [(mpW-)pW-(mpW-)$cW]. It is a sort of orthogonal Equihopper.

This might never be possible, but I wonder if there could be a way to specify a piece that captures like a cannon, but both parts of the move—before and after the mount—must be the same distance, and there can be any number of other pieces jumped over on the either leg.

Well, bracket notation is currently only implemented for two-leg moves: it tries to reduce those to a commensurate atom, and ignores all later atoms, except their leaper/slider nature for determining if a y should be inserted. So when it works it is basically coincidence.

If you assign a new move to another piece, you can see which XBetza the preprocessor produced from your bracket notation. Which in this case is: RyafufafcfabR . So you see it did understand that the move could end at R, and it did understand there were 4 legs (3 as), it did understand it had to switch from slider to leaper after the first leg. It got a bit confused about the directions, because you added an f where no f was really needed, because that is already default. And you did that after a mode modifier (while I always do directional modifiers first), so that it did not notice it. Hence it adds a redundant f before the u and c. But I don't think that would hurt. It did understand that two continuation legs were f, and the 3rd b.

What it did not understand is that the 4th leg was D. Because it never looked at it, other than classifying it as a leaper, so that it should not toggle back the W to R. So it was close, but no cigar...

I'm trying to build a piece that moves like a normal Rook, and then, if there's an empty square in the next space forward and an enemy piece in the next space beyond that, pulls the enemy piece into the empty square. I'm still a bit inexperienced with u, but it seems to me that the bracket notation should be built thus:

• The basic move, R
• The rest is optional, so ?
• The next space is to be a destination, so ufW
• Then capture the enemy piece in the next space, so -cfW (said enemy will then go to the first space)
• The jump back to where the Rook move ended, so -bD

But when I try [R?ufW-cfW-bD] out in the Sandbox, the enemy piece and moving piece just end up in each others' places. I'm not sure what I'm doing wrong here.

I like that idea for the %. It's actually quite intuitive for the symbol's conventional meaning. The only question is, what effect would that have on a Rook on a rectangular board? If the board is 12x16, would the half-Rook move six spaces sideways and eight spaces vertically? (That actually would make the most sense to me.)

As for using ' and " to "retire" d, I think the letter would have to be retained for backward compatibility. Otherwise, I think we'd have freed the L and J atoms by now. (I personally would welcome seeing all three characters freed up for potential new uses -- like, an atom for Bison (CZ), mainly for use with Cheetahs, Sabertooths, and related pieces, which I wouldn't try to do with the smaller number of free atoms we have right now.)

On a (mostly) unrelated note, I'm finding trouble when I try to put more than one pair of parentheses into a move, whether nested or sequential. For an example of the latter, I've tried expanding the Springer's pya(b)K move so that it can bounce off more than one target, but pya(b)(pa)K (or even pya(b)(pa)2K) doesn't yield anything but an error message ("No atom at end").

PS: With some experimentation, I've found that shQ and shK yield "all directions except forward and backward," while vhQ and vhK yield "all directions except left and right." I just thought I'd point that out; I think it'd be worth documenting. :)

gafQ3

Bracket notation is a proposal for future improvement, and basically not implemented. A few cases representing commonly used pieces such as Griffon are recognized, and handled by a pre-processor that substitutes the corresponding a-notation. The S is apparently not amongst the recognized cases. (This might be easy to fix.)

Range limits on hoppers has always been a problem in XBetza, because you would really need two ranges: one for before, and one after the mount. The rules for range toggling (triggered by g or y) are such that the specified atom + range count for the first leg, that finite range turns into infinite, and infinite into 1. So gQ4 means up to 4 steps to the mount and infinitely many behind.

Bracket notation would solve this, by allowing you to specify a range in each leg. But it is not implemented yet.

Reusing an existing symbol has little advantage if you have to introduce a new symbol to resolve the ambiguity it causes. IIRC 'halfling' is a (flexible) range specification, so it would be more natural to indicate it as a (non-numeric) suffix than as a modifier prefix. I would suggest the % sign, as the actual range should be a fraction of the free path. We could even give different meaning to W% and R%.

As a symbol on its own checking for a piece is already done by p. If a combination of symbols is to be used for specifying whether it should be friend or foe, I'd rather use p' and p" than a t. The quotes could be used to diversify other modifiers as well. E.g. c' could be friendly capture, and c" friendly or enemy capture. Than d could be retired.

Indeed, screen = mount = platform. Two platforms you can already do by [pB-pB-cB] or pafpafcB.

@Aurelian: What do you call "platform"? Do you mean the "screen", as defined in https://www.chessvariants.com/piececlopedia.dir/pao.html?

I think a nice feature would be to allow multiple platforms for cannon like pieces. Personally as I don't like the idea of bishops in a Xiangqi or Janggi environments I'd like a pRppcR instead (where pp stands for 2 platforms). Some food for thought.

Somethings i want to note and some ideas

• gK should be able to be written as [jS?Q] but the latter moves completely different
• gQ4 i expected to be a grasshopper, not a lion, limited to 4 tiles in total, the case of up to 4 tiles after hurdle can be constructed using square brackets [gQ?Q3] (i think, doesn't work in the diagram on the page)

• h on it's own has no definition, something like relative half, from the halfling, could work
  • This does make left-only half impossible as lh and hl already have a meaning, you could use a punctuation like a comma , to seperate them so that the compound doesn't work, with this , you can make a move that's initial and non-leaping, but does not create e.p. rights i,n
• t could be used for checking if there's a piece there, adding c or d to specify enemy or ally piieces

Moves that are only allowed when you are attacked are much harder to implement. They are a form of enemy induction. (Which the I.D. also doesnt't implement for that reason.)

I actually was thinking that it could be something that the new off-site AI you mentioned being in the early stages of working on might be able to manage. And HaruNY did point out a few other cases where the rule is used.

It's something to consider, at least, as you're building said AI engine. :)

So I will change the definition to that it should not go back to the previously visited square on the path.

That, I think, would be the ideal. :)

A good algorithm would be to tabulate first which squares you can reach in one step, and then from all of those take another step to tabulate those you can reach in two steps, eliminating duplicats at every stage.

That can be great, though sometimes where a piece can move from a square depends on where it came from. With a Rose, for example, any square that can be reached in 2 or 3 steps has two ways of approaching (unless blocked), and each of those two ways has a different allowed exit -- four if the Rose is allowed to go full circle. Some complex bent sliders, the Combine being the most common, also have overlapping moves. The algorithm would be perfect for pieces like the Ubi-Ubi or Shogi area movers, and probably would also improve regular radial sliders and oblique riders (especially those with cannon, grasshop, or juggernaut moves), but there should be some way to allow for "this way in, that way out" (like ignoring the elimination of duplicates after a turn modifier is encountered).

I am not sure that rules like this would qualify as being part of the move. Betza notation is supposed to describe the pseudo-legal moves of a piece, and that some of those might be forbidden in a real position because of the constellation of pieces outside the path, is what makes the difference between legal and pseudo-legal moves. Moves of pieces in a variant that has a checking rule are not written differently than in a variant that hasn't.

A rule for not being allowed to move out of attack can be implemented in the AI relatively easily: you test for in the reply move whether you can capture to the evacuated square. This is how the ban on castling out of (or through) check is implemented to. The AI is not aware it is in check, but on castling it marks the King's origin and passed-through squares as 'royal' e.p. squares, and considers any capture-capable move to it in the next half-move as an (immediately winning) King capture.

Moves that are only allowed when you are attacked are much harder to implement. They are a form of enemy induction. (Which the I.D. also doesnt't implement for that reason.)

-King can't castle when in check in Chess

-King may not move out of check, except to capture its singular attacker in Makpong would be !mKcK.

-Vaulting Camel-King from fairy chess problems would be K!!C

-Transmuting King from fairy chess problems (King but when it is threatened, moves only like the threatening unit(s) (!K+Orphan))

-Tengu pieces from MAD Chess

-etc.

Not if the move is a leap. Imagine, for example, a Flame-ingo with [CX;KD].Or, probably more to point, a piece with K[T;K] -- or should that be K[T;abK]?

In the former the burn would go to all 12 squares, as none of the KD steps is perfectly aligned with CX. In the second case one of the moves would go exactly in the backward direction. Although it doesn't seem a disaster having to write ab, I guess it shows that there really is no reaason to forbid moves with another stride. So I will change the definition to that it should not go back to the previously visited square on the path.

That reminds me that in XBetza at some point I defined it as not being allowed to return to any previously visited square, to prevent that aaK could make a turn pass by triangulating. Of course this was pretty much unimplementable. Now as the Ubi-Ubi (which basically has an unlimited-range area move with Knight steps) shows, area moves really need a dedicated generator if you want to treat those efficiently. (As is very important for the AI.) There is just too much overlap between them. (a)2K has 456 possible realizations, but these reach only 49 squares. So each move is generated some 9 times on average. A good algorithm would be to tabulate first which squares you can reach in one step, and then from all of those take another step to tabulate those you can reach in two steps, eliminating duplicats at every stage.

Good question. It makes less sense to exclude it here. OTOH, normally this square has to be empty, or it would have blocked the move.

Not if the move is a leap. Imagine, for example, a Flame-ingo with [CX;KD].Or, probably more to point, a piece with K[T;K] -- or should that be K[T;abK]?

Well, I tried to generalize it. But I think I blew it, because I was thinking in terms of steps rather than moves when I wrote it.For the conventional 'orthogonal planar move', which we would write here as [vR.sR], the point is that the steps set up a grid (in this case containing every board square), and that you only have to consider what is on that grid. But (on an empty board) every square of the grid could be reached by zero-or-one move of the first kind plus zero-or-one move of the second kind. The area spanned by the move (which must be empty) consists of all squares that could be reached by fewer or shorter moves of both kinds.

Yeah, I was thinking Rook/Bishop when I was reading it, not Wazir/Ferz. This explanation is much better, and reflects what I recall.

I used the dot because I saw it as a multiplication. A comma could also be suitable, if you see it as coordinates.

I'm actually seeing the planar move as a simultaneous two-way move; that's why I was suggesting the ampersand. (Another symbol that makes sense to my brain is the slash -- though it's also one that I think would probably confuse the computer!)

Also, I'd wonder whether directly backwards is part of the default, or would have to be added.

Good question. It makes less sense to exclude it here. OTOH, normally this square has to be empty, or it would have blocked the move. So it only becomes an issue for a burning Grasshopper move. As it seems quite unlikely anyone would use that, there seems little harm in excluding it. Just for uniformity with other continuation legs. It is easy enough to add it through ab, while it would be very hard to exclude it.

the description there doesn't match up with the explanation that I recall being given to me.

Well, I tried to generalize it. But I think I blew it, because I was thinking in terms of steps rather than moves when I wrote it.For the conventional 'orthogonal planar move', which we would write here as [vR.sR], the point is that the steps set up a grid (in this case containing every board square), and that you only have to consider what is on that grid. But (on an empty board) every square of the grid could be reached by zero-or-one move of the first kind plus zero-or-one move of the second kind. The area spanned by the move (which must be empty) consists of all squares that could be reached by fewer or shorter moves of both kinds.

I used the dot because I saw it as a multiplication. A comma could also be suitable, if you see it as coordinates.

The Ubi-Ubi is of course a sick piece. The problem is that the current implementation of the I.D. tabulates each angular realization of a given move, and for multi-leg moves that can freely change direction that quickly explodes. Even the Tenjiku area move, (a)2K, produces some 500 trajectories.

Ughh, that would be a problem indeed. Better use a semicolon for the burning then.

Something just occurred to me about punctuation in the notation. How would : (for burn moves) interact with the use of colons in Interactive Diagram coding?

(I think that this is what Bob had in mind too, but he wrote the u in the wrong place.)

Guilty on both counts! :)

I think that this is an excellent documentation for full bracket notation, but for two or three quibbles.

One is a typo: in the paragraph on Burning, you say "color" instead of (the first time of) "colon." Also, I'd wonder whether directly backwards is part of the default, or would have to be added.

Second, while that's a dead-on explanation of a as used in this context. I think it's worth mentioning that a(b) or ab can be used for any direction including exactly backwards. (My experience is that for former works, but not the latter.)

About planar moves: This needs a clearer explanation of what a planar move is. Besides being convoluted (for brevity, no doubt; "Hello, Mr. Kettle"), the description there doesn't match up with the explanation that I recall being given to me. Also, this might be a better use of & (as referred to in another Comment) as being both more visible and (arguably) more intuitive than ..

PS: The Ubi-Ubi as (a)N is pretty simple, though it does seem to overwhelm the system (at least, on my computer, which is particularly powerful).