Check out Atomic Chess, our featured variant for November, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Single Comment

Betza Notation. A primer on the leading shorthand for describing variant piece moves.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on Wed, Oct 9, 2013 10:14 PM UTC:

I did some Google search, and I found some statements about Betza notation that are not reflected on this page.

  • The Wikipedia claims that there is a modifier 't', for 'then'. A Griffin would be WtR. On this page it is described as [WR]. Has this notation superceded the t modifier? I have no reason to doubt that the mentioned t-modifier is genuine. Proposing 'then' as name for an operator is typical Betza thinking, and he mentions below that he was very careful to stay away form any puctuation stuff (actually mentioning brackets in that context!)
  • The Wikipedia articles on large Shogi variants do use an extended Betza notation that accounts for the Lion by means of the symbols d and dh, where the double-move component of the Lion is written as dK, and that of the Falcon and Eagle as dhfW and dhfF, respectively.
  • I found a comparatively recent PDF document by David Howe (on this website! http://chessvariants.org/dictionary/BexNotation.pdf ). He calls the extension proposed in there 'Bex Notation'. But Bex seems to conflict with what is described on this page. In particular, Bex notation uses the brackets for a completely different purpose, namely as 'exotica operator'. And it uses parentheses for the purpose brackets seem to be used here (except in a more general way, where you could group anything with them). I must admit I like notations that somehow parenthesize better than those with an internal t 'connection' operator, as the latter would raise questions about operator priority (i.e. does WtF2 mean [WF]2 or [WF2] ?), which you could not solve without any form of parenthesizing if you wanted to express the alternative meaning. The brackets used on this page seem to imply mrore than just grouping, though: they really alter the meaning of concatenating the atoms. Normally WF would mean K (= join the move sets). Within the brackets it means WtF (serial steps). I don't like that. In this respect Bex is good: parenthesis just for grouping are much more flexible, and using () will avoid confusion with the [] introduced here. You would need some explicit operation for serialization, however. Indeed Bex proposes the hyphen or double-hyphen for this, to replace the 't' modifier. I don't know if this is wise; For one, there seem to be more possibilities as 'general forward' or 'any direction', as the - and -- seem to indcate, respectively. (E.g oly sideways, as in the Tai-Shogi Hook Mover, which would follow an R move by an R perpendicular to it.) It seems more powerful to just have a single serialization operator, which defaults to 'the same general direction' (which I called forward in my proposal for describing continuation steps in coordinates rotated to fit the previous step that I made in the previous post). And then use directional modifiers to specify the non-default cases. The - seems more readable for this as the 't', because it is really a binary operator, while the other modifiers are all unary prefix operators. So it would be good if the serialization operator stands out from the others, which - certainly does. (The -- is a very bad choice, however, as in some fonts it can hardly be distinguished from the single -.) I would propose the simple concatenation to couple less tightly than the -, however. I.e. W-WF should mean (W-W)F = (nD)F, and not W-(WF). The latter seems rarely needed; normally the continuation step would have too many directions, such that you need directional modifiers to limit them, rather than that you would like to expand them by joining move sets of several atoms. In this case there is need for a directional modifier that indicates 'all directions'. Normally this would be implied when you use the unmodified Atom, but if in the context of a continuation step 'forward' is the default, it is suddenly needed. It seems better to use -a than to use --; the 'a' is on par with f, b, v, s etc., so it should be the same type of symbol. A piece that travels through a path of two King steps (an 'area mover', in Tenjiku Shogi terms) would be K-aK in my proposal, while K-K would be the same as K2. K-aK is not yet a move with Lion power, though, just a bent leaper. An extra modifier is needed to indicate something internal to the path can be captured, i.e. the move is that of a locust. How about using 'x' for this? This is after all the symbol for capture, while - is often used for non-capture moves. So they make a nice logical duo. KxaK would then be a two-step King move that can continue after capture on the first step. The prefixes m and c would just pertain to the normal capture at the end of the move. So fmFxF would be a checker: it makes two collinear Ferz steps, but only to empty squares (hence the m), and it must capture on the way. The Lion would be KDANKxaK. I don't see any need for the [xo] component proposed for the Lion's null-move capability in Bex; this could be written without any new symbols as K-bK: make a non-capture King step, and then make it back. There also seems no need for the d / dh modifiers. I don't like the Bex proposal to use y for royal. I think this letter should be reserved for bifurcators, somehow. Much better to use 'k' (as in 'King') for royal pieces. OTOH, an O atom for unconditional null moving (unlike the Lion's, which is dependent on the proximity of an empty square) seems a very good idea, as is the 'i' for initial move. I would like to have a better notation for hoppers / bifurcators. The g/p modifiers are much too limited in scope, as they assume no directional change on hopping. I would be nice to have a binary operator connecting two moves that indicated a hop should occur between them. Like cR+R for the Canon's capture move, and mRcR+R for the Canon. And Q+K for the Grasshopper. No need for p and g at all. And it would also be able to handle cases of a bifurcating hopper, like R+B, which would move to the platform as R, and then change direction to continue as B in the outward direction. (For + any other symbol or letter could be used, perhaps ^, or even h.) Similarly RyB could mean a bifurcator that changes direction just before it bumps into an obstacle. RxB would be the locust corresponding to the hopper.