Comments/Ratings for a Single Item

I am not sure if all these should be considered the task of move notation. Basically the purpose of Betza notation is to indicate geometrical patterns on the board, in combination with the occupancy of the destination. 'i' is already a concession, justifiable because it is such a common case.

Immobilization and Hia power are not moves. They are spells. They certainly have a geometric aspects, which could be expressed in Betza notation. But there is no need to combine their specification with that of the move; that needlessly raises the problem how to distinguish these specifications.

The Crooked Nightriders can be made with the aid of parentheses for delimiting repeating modifier groups. See the Nachtmahr article.

Two possibilities for the I (Imitator) atom:

1. Attaching a number so that more than just the very last piece is Imitated; for example I2 for the last two pieces. Could be modified using lower-case letters for things like only the last two opponent's pieces.
2. Allowing for a Protean; that is, a piece that assumes the powers of the last piece it captures. Maybe could be done as cI or xI. (It could also be a modifier for M; cM could be the basic Protean, cM3 for something that imitates the last three pieces it's captured, etc.)

I recognize that these might be more easily said than done, to the point of not being doable at all, but it's a thought.

I do second Niels's proposal of ni for "not initial," as it would expand possibilities quite a bit. With the rest, of course, you're quite right.

Also, with parentheses notation, there should be some way to indicate "as many times as the board's size will allow," basically duplicating the function of a double atom letter. (If nothing else, it'd make copying those complex moves from one game to one with a larger board less of a hassle; no need to figure out manually what that number would be.) I've been using # in my own notes, but ! or " might make more sense.

Edit: Never mind the latter. It can be done by just using no number at all. At least, the PTA treats it that way.

For ranges on atoms 0 (zero) can be used for indicating unlimited range. So it would be logical to do that here too. Problem is that it is not obvious what the maximum number of repeats should be, (e.g. in case of crooked path, or a Reflecting Bishop on a non-square board) and that it is rather harmful for efficiency to use a too-large value. (It is like defining a Rook as WafWafafWafafafW...  with ever longer lame leaps, the path of those tested over and over again for emptiness.) That also makes it difficult for the Diagram to determine it. Remember that 'artificial intelligence' really is a eufemism for 'artificial stupidity, applied in brute force'.

Life will become easier when I will extend the XBetza parser to handle the parentheses directly, instead of through a preprocessor that makes a different move for every number of repeats. The current move generator already uses a system where you can have a move of very many legs, all optional, for doing old-fashioned zB or qN. Provided that the legs are just direction changes of a slider/rider path. It can even do (grass)hopping versions of those moves. This is an efficient method, and the path can be made far longer than needed, without any impact on efficiency. The move generator would just traverse the entire path once, emitting a move at every step where continuation is marked as optional, and stop when it hits a piece or goes off board, no matter how many optional continuations remain in the definition.

Do you know any variant at all that has a 'not-initial' move? I don't like it much to combine modifiers that individually have a different meaning. For modifiers the rule has always been that the order is arbitrary.

I don't know any that currently exist, but I've had some ideas for a while now (since before joining the site) that would apply here. For example, a creature or assassin (or creature-inspired assassin) that leaps like a Sabertooth on its initial move, but can slide like a Queen (or at least a Heavenly Tetrarch) afterward. It's not just for Dealer's Chess or Unnecessarily Complicated Chess, either; that assassin would work well in an expanded Desert Dust.

And while it doesn't have to be ni (though I'm not sure what else to use, since ii is already in use), there is some precedent for order mattering in the case of h: lh and rh mean something different from lr and hr. (I think there's a distinction between ck and kc as well.) And looking at the XBetza system, I can't really see any reason besides this to put the n before the i (mnemonically, the i most logically comes first, and in practice I don't think I've ever seen it anywhere else).

Well, directional modifiers are different, as some directions must be specified by a pair of them. And h has no meaning of its own, unlike i and n, and kc and ck do mean the same. (It is just that plain k means capture King only, and the other capture everythin but King, so that k is a toggle.)

I am sure you can think of something that moves according to any kind of rule, no matter how far fetched... But the fact that you don't know any variant that already requires it is more significant. The ID can already handle this case, should it arise, by immediately morphing the piece that is originally present into another one that does have the move you want it to acquire. So there really is no need for an i in the first place; that XBetza supports it is only because it is so common.

In Scirocco one of the promoted pieces induces N moves like Q3. This poses the problem in XBetza you usually have, when legs of a move use incommensurate atoms. And the usual solution is to express those as multiples of their 'common denominator', usually K steps. Q3 already does consist of K steps, so one has to write the N leg as two transparently glued K steps: xyampafsQ3. After the xQ3 leg the ya toggles the range to K for the following legs. An mp leg in the arbitrary direction followed by a 45-degree turn for the final leg add a Knight move to that.

In bracket notation this would be [xQ3-aN], but I am not sure the ID can already handle oblique after orthogonal/diagonal.

Revisiting this, especially the latter part, in light of the Relay Thaumaturge in Unnecessarily Complicated Chess.

Since a normal Thaumaturge is KCZ, if I want the piece to share all its moves to all the locations, the Relay Thaumaturge would (using bracket notation) be KCZxaKxaCxaZ[xK-aC][xK-aZ][xC-aK][xC-aZ][xZ-aK][xZ-aC]. Did I get that right?

That is the right principle. But as the quoted text says, I am not sure the ID would understand this, as bracket notation is not fully implemented.

Since it is always clear in bracket notation what belongs to the same leg, I suppose there would be no reason to forbid compound legs. The XBetza compiler already expands the moves like you did here, not for different atoms, but for different directions of the same atom. (So aK gives 56 moves in the move table!) Your Thaumaturge could then be written as [xKCZ-KCZ]. Of course there is currently no support for this at all in the ID (except for the WF case implied by K), but it is a thing to keep in mind when implementing direct compilation of the bracket notation.

I actually was going to suggest a [xKCZ-KCZ] form for some future update. But there are more pressing things for this (such as implementing the S = AD and T = GH atoms you mentioned earlier*).

Thanks for the helpful reply.

*I also wonder of this could be extended to KX, SX, TX, and so on. I doubt it, but it's a thought.

I suppose extension should be easy. The point is that the betza parser already considers orthogonal and diagonal moves one family. So rather than splitting up K into W and F by some preprocessing, it considers W and F a form of K with a different (incomplete) default direction set. So apart from the different interpretation of the directional modifiers and the default for it, they would all be considered moves with a (0,1) step, (even F!), yet to be (pseudo-)rotated in several orientations as specified by the direction set. Encountering an X suffix at that point would increase that step to (0,4). In fact KX already works now! It is just a matter of also recognizing S and T as atoms with radial symmetry, and step (0,2) or (0,3), respectively. Then the SX and TX come for free.

[Edit] OK, I added the S and T atoms in both betza.js and betzaNew.js. I must fix the Spiral-Chess Diagram now, though, as I represented the spiral move as S there, counting on the Diagram script ignoring that. But now it would give the King an extra Alibaba move...

Outstanding! I've tried out the S and T a bit, and I think it'll simplify a lot of things -- like the Linebacker Pawn's "push" move, to [fhmS-ubcK] and [ifhmT-ubcK] (unless, of course, I should put the u on the first segment; I have a hard time with that bit).

As an aside, I experimented with KY, SY, and TY. The ID only appears to recognize the orthogonal move with those, adding a (2,2) leap so that TY = AX (= (5,2) = Bharal), where I'd expect either AXGY or AXCY* (depending on how one wants to interpret it). I don't know if anything can -- or even needs to -- be done about that.

*AXCY = my Thoroughbred, which would turn the Midnighter -- my second-favorite piece of my own invention -- from NNAX0CY0 to NNTY0.

The u is in the right place; unloading occurs on the start square of the move, unlike the other mode modifiers, which specify a condition on the destination.

I suppose I must still make the preprocessor that handles the bracket notation recognize the S and T, though; in translation to normal XBetza every leg in your move would have to be expressed in K steps, and it must know how many.

[Edit] OK, the S and T should now also work in the bracket notation as first leg, when a step or slide follows. Like K it works in a bit of a kludgy way; it determines the range of the leap, but the symmetry is actually determined by the atom in the second leg. So if you used K there, it would already have interpreted and A, D, G or H as if they were S or T. Based on the reasoning that if the first leg was a 4-fold atom, no matter how you bend, you would always know whether the next leg is orthogonal or diagonal, and use the corresponding 4-fold atom there rather than K.

Using X in the first leg of a bracket notation does not work yet.

KY is not supposed to work. I can find no logical meaning for it. Oblique moves already are 8-fold symmetric, and you can make all such move sets by extending the regular 4-fold atoms. To extend the radial 8-fold atoms to larger distance the X is already enough.

Just to make sure I have it right:

There's no way, in the current implementation, to represent the capturing abilities of the Coordinator or Pincher.

There's no way, in the current implementation, to represent the capturing abilities of the Coordinator or Pincher.

Pincher capture is a form of (conditional) burning. It is not a move, so I don't think it should be represented in the move notation. If the Interactive Diagram were to support it, it should be through the burnZone spec (and captureMatrix for indicating which piece burns).

Now there is of course a spatial aspect to a burn zone, and its extent can very well be defined in Betza terms. As the ID already does. In this definition it is implied that it specifies capture, or in fact rifle capture at all the indicated locations, as an automatic side effect (i.e. mandatory when possible, but not required to be possible). We could elaborate on this definition by allowing modifiers on the atoms. E.g. dK would specify burning of all adjacent friendly pieces. Then you could also specify multi-leg burning. Pincher capture is a form of bouncing grasshopper capture, [dD-bucW]. (This uses the d-u kludge for specifying friendly hopping over the D squares, to capture at the jumped-over W squares.) In a burnZone definition the capture would be understood to be rifle capture. (So perhaps the c should be omitted, as in burnZone specs it is implied that the destination indicates enemies there disappear.)

Coordinator capture (also a form of burning) would be harder to describe. It would be multi-hopping hook-mover hopping to the friendly King, followed by reversal of the second leg of the hook move to make the capture. Problems in expressing that in the current XBetza implementation is that there is no way to specify friendly King capture (so the capture-unload trick cannot be used for the friendly hopping): k captures the enemy royal, ck every enemy non-royal, but dk would logically mean every friend or the enemy royal, with is not redundant, so there is no justification for a special interpretation "every non-royal friend" in analogy with ck (which was otherwise redundant). And this would not be the interpretation we need (only the friendly royal) anyway. The second problem is that although multi-hopping can be indicated with the aid of parentheses, the 'iso' mechanism would not be able to exactly reverse a combination of hops. Not even if we specify that repeated use of i would refer to ever earlier previous slider legs rather than always the latest: a mechanism to force an equal number of hops in the reverse leg would also be needed. A simplification would be to allow pp as indication for "hops arbitrarily many". Then [ppcR-sppk'R] would do it, with the conventions that use of an explicit c in the definition of the burn zone indicates the victim of the one rifle capture it will do, and the apostrophy in k' means friendly King. (This use of apostrophe or double quote on mode modifiers could be used as a general mechanism for indicating friend-only or foe-only, so that it could also be used on p, and the d modifier would become redundant, and could be replaced by c'.)

Don't hold your breath until any of this gets implemented, though. It is already possible to do these captures  with the aid of additional scripting, as can be seen in the Ultima Diagram. Considering how extremely uncommon these pieces are, that seems good enough.

Short answer: Yes, that's correct.

Don't hold your breath until any of this gets implemented, though. It is already possible to do these captures  with the aid of additional scripting, as can be seen in the Ultima Diagram. Considering how extremely uncommon these pieces are, that seems good enough.

I don't know about "extremely uncommon," but they certainly are uncommon. I'm not asking for a rush on it, though; I just wanted to be sure that there wasn't a way of doing them that I was missing.

That said, using pp for "hops arbitrarily many" does have some appeal of its own, especially for certain large Shogi variants.

@HG: I understand your point of view about the need for S and T. OK. But when you write S 'Second ring', T 'Third ring', don't you think that "ring" is a wrong term there?

Yes, you are right, 'ring' might be confusing. Better to say 'second square'.

Since it is always clear in bracket notation what belongs to the same leg, I suppose there would be no reason to forbid compound legs. The XBetza compiler already expands the moves like you did here, not for different atoms, but for different directions of the same atom. (So aK gives 56 moves in the move table!) Your Thaumaturge could then be written as [xKCZ-KCZ]. Of course there is currently no support for this at all in the ID (except for the WF case implied by K), but it is a thing to keep in mind when implementing direct compilation of the bracket notation.

I just wanted to request that you let me know if/when this is imiplemented. (I say this, understanding that it may not be this year.)

Oh, and don't forget to add what happens with q on single-letter sliders to the list of "new/altered" modifiers.

Oh, and don't forget to add what happens with q on single-letter sliders to the list of "new/altered" modifiers.

Well, up to now it was an undocumented feature, and I am not sure if it is a desirable one. qR does the same as [W?DD], but the latter is a lot clearer. To understand qR you would have to know that q is overloaded, and doesn't mean 'circular' in this context, but something totally unrelated. Most people would not know that.

If I knew for which Diagram I implemented this, I would change it to the bracket notation there, and no longer support q in this meaning in the general script.

@HG and Bob: just a testimony. I had not followed your discussion, but yesterday I indeed tried qR, qQ, on the Diagram, and I was very surprised to see that it gave [W?DD], [K?SS]. I was wondering why is this related to a circular move. This is what HG is saying now if I don't misunderstand.

To understand qR you would have to know that q is overloaded, and doesn't mean 'circular' in this context, but something totally unrelated. Most people would not know that.

They probably would know it if the feature was documented.

But, I guess it's up to you. Perhaps something related to j (like jjR, or maybe jyW) would be more intuitive.

I was wondering why is this related to a circular move.

That actually is the probolem that H.G. is citing about this, and it's a valid concern. I rather like it, since sliders are different animals than steppers and leapers, but I've only put it in one place, which doesn't yet have an ID, and I'll readily change to [K?SS] or (ampfaf)K or jjQ or whatever works best.

Am I defining this correctly?

my(adaubacfab)4Q

This is supposed to move as a queen and capture any enemies next to the destination square if there is also an adjacent friendly piece immediately opposite. It doesn't seem to work exactly how I want in the sandbox, so what's wrong with it?