Check out Symmetric Chess, our featured variant for March, 2024.


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

Comments/Ratings for a Single Item

Later Reverse Order EarlierEarliest
Betza notation (extended). The powerful XBetza extension to Betza's funny notation.[All Comments] [Add Comment or Rating]
Bob Greenwade wrote on Fri, Mar 15 06:28 PM UTC in reply to Fergus Duniho from 04:44 PM:

Fair enough. :)


🕸Fergus Duniho wrote on Fri, Mar 15 04:44 PM UTC in reply to Bob Greenwade from 04:32 PM:

if you could take a glance at that when you have a moment and pick out any problem symbols (the Berolina would be a leading candidate), and hopefully suggest alternatives, I'd appreciate it.

No, I don't have the character sets memorized, and I don't think it is a good idea to go beyond ASCII for piece notation.


Bob Greenwade wrote on Fri, Mar 15 04:32 PM UTC in reply to Fergus Duniho from 04:02 PM:

Since this site uses Literata, Noto Sans, and Courier Prime, you may want to limit yourself to a subset that is supported by all three of these fonts. Of these, Courier Prime has the most limited support for character sets. Besides ASCII, it supports only Latin Lowercase, Latin Uppercase, Numbers, Common Latin, and Punctuation. Literata and Noto Sans both support all of these, as well as others.

That still leaves me a bit uncertain. I just edited Short Sliders with some Unicode symbols; if you could take a glance at that when you have a moment and pick out any problem symbols (the Berolina would be a leading candidate), and hopefully suggest alternatives, I'd appreciate it.


🕸Fergus Duniho wrote on Fri, Mar 15 04:02 PM UTC in reply to Bob Greenwade from 02:38 PM:

If that means that, essentially, all of Unicode would be open for use on all systems, then that opens up many more possibilities (for the "special custom codes").

In theory, but it's a rare font that fully supports all of Unicode. Since this site uses Literata, Noto Sans, and Courier Prime, you may want to limit yourself to a subset that is supported by all three of these fonts. Of these, Courier Prime has the most limited support for character sets. Besides ASCII, it supports only Latin Lowercase, Latin Uppercase, Numbers, Common Latin, and Punctuation. Literata and Noto Sans both support all of these, as well as others.

My concern was support on people's systems at home; I expect that there's still a small (but, admittedly, rapidly shrinking) percentage of systems that support ANSI but not Unicode.

Those would have to be very old computers. According to the Wikipedia article on UTF-8, "UTF-8 is the dominant encoding for the World Wide Web (and internet technologies), accounting for 98.2% of all web pages, 99.0% of the top 10,000 pages, and up to 100% for many languages, as of 2024." According to the same article, Windows Notepad only supports UTF-8.


Bob Greenwade wrote on Fri, Mar 15 02:38 PM UTC in reply to Fergus Duniho from 12:07 PM:

Note that this site uses UTF-8. So there is no point in sticking to Windows-1252 in the mistaken notion that it may be better supported. That said, ASCII has the advantage of being on most keyboards and of being most familiar to people. It’s also a subset of UTF-8 that can be written as single 8-bit characters.

If that means that, essentially, all of Unicode would be open for use on all systems, then that opens up many more possibilities (for the "special custom codes").

My concern was support on people's systems at home; I expect that there's still a small (but, admittedly, rapidly shrinking) percentage of systems that support ANSI but not Unicode.


🕸Fergus Duniho wrote on Fri, Mar 15 12:07 PM UTC in reply to Bob Greenwade from 04:21 AM:

the Windows-1252 character set that I'm suggesting to use as the basis (because even a system without Unicode installed should have at least that much

Note that this site uses UTF-8. So there is no point in sticking to Windows-1252 in the mistaken notion that it may be better supported. That said, ASCII has the advantage of being on most keyboards and of being most familiar to people. It’s also a subset of UTF-8 that can be written as single 8-bit characters.


💡📝H. G. Muller wrote on Fri, Mar 15 08:26 AM UTC in reply to Bn Em from Thu Mar 14 11:52 PM:

And while hexagonal boards may be in scope for the ID, I imagine 3D and hyperbolic boards are far from it ;‌)

Representation of 3D and 4D 'boards' is mostly problematic for the human player. One often resorts to displaying 2D slices of the board next to each other, which basically maps it to a larger 2D board. Chess programs in fact use the very same technique to map 2D boards to their 1D memory, storing them row by row. In all these cases separators between the slices would be needed to prevent 'wrapping' from one slice to the other. Usually this is done by separating the slices by enough inaccessible cells of the 2D representation that the leaper with the longest range cannot jump over it.

E.g. for a 5x5x5 variant with range-2 leapers ('Knights') you would map it to a 33x5 (or 5x33) board, with five 5x5 playing areas separated by four 2x5 'guard bands'. On this board an orthogonal step perpendicular to the slices would be a (7,0) leap, and is representable in XBetza as WXX. So the Raumschach Rook would be RWXX4, a Raumschach Bishop BHX4DXX4FXX4.

files=5 ranks=33 graphicsDir=/graphics.dir/alfaeriePNG35/ squareSize=35 lightShade=#FFFFCC darkShade=#FFCC00 holeColor=#000000 rimColor=#000000 coordColor=#FFFFFF useMarkers=1 borders=0 maxPromote=0 promoChoice=QUNRB firstRank=1 symmetry=mirror hole::::a6-e7,a13-e14 pawn::fmWfmWXXfcFfcFXX::a2-e2,a9-e9 morph=/////////////////////*///////* knight:N:NDXYDXHXXWXXXXHXXXXNXXXX::b1,d1 bishop::BHX4DXX4FXX4::a8,d8 unicorn::CX4NXX4::b8,e8 rook::RWXX4::a1,e1 queen::QWXX4HX4DXX4FXX4CX4NXX4::c8 king::KWXXHXDXXFXXCXNXX::c1

💡📝H. G. Muller wrote on Fri, Mar 15 07:00 AM UTC in reply to Bob Greenwade from Thu Mar 14 10:44 PM:

It's trying to get caib[qN] to work that would be the challenge.

Well, now that generalized burning is been written with the aid of legs behind a semicolon, another punctuation (say comma), could be used for generalized rifle capture. Burning and rifle capture are related: there is a set of captures, burning automatically does all of those that are possible, rifle capture has to select one of those. Pure rifle capture is a null move followed by the capture option. Suppose O without range would mean null move, then [O,cqN] would be a rifle-capturing Rose. There still is the issue of whether the rifle part can be optional. I would say no, as the entire moves in a Betza description are already optional. So by making it mandatory to do at least one of the rifle captures, you can still allow the move without capture by specifying it separately. Like for Odin's Forest Ox: N[N,cK].


Bob Greenwade wrote on Fri, Mar 15 04:21 AM UTC in reply to Bn Em from Thu Mar 14 11:52 PM:

you'd (apparently) lean toward using ß for Sexton, while I'd use it for Switchback

We're technically not contradicting each other; I was using capital ⟨⟩, as is usual for atoms, whereas Switchback, whilst really something that XBetza would tend to spell out explicitly, is definitely small ⟨ß⟩ material

That depends; the Windows-1252 character set that I'm suggesting to use as the basis (because even a system without Unicode installed should have at least that much) only has ß. That, I believe is the lower-case letter -- which would rather spoil my use.

By the way, the full XBetza for the Switchback would be afq(afzafq)K(afqafz)K, which I think would be quite rarely used and only needed to be "atomized" for a rifle capture, bent slider, or something similarly strange. So not having it wouldn't necessarily be a big loss, and one of the other letters in the set (like maybe Ï? Or Ş, if all of Unicode is opened up) could still work if I really want it.


Bob Greenwade wrote on Fri, Mar 15 12:59 AM UTC in reply to Bn Em from Thu Mar 14 11:52 PM:

I may be wrong, but trying to get XBetza to manipulate a Rose path in that way once it's been defined might be more convoluted than it appears

You may also be right, at least when using a simple qN definition. If that turns out to be the case, then I'd have to find a way to program it using whatever custom-move system that H.G. (and/or Fergus) come up with.


Bn Em wrote on Thu, Mar 14 11:52 PM UTC in reply to Fergus Duniho from 03:34 PM:

why you want to expand xBetza

As with Bob, really my answer is (at the moment) that I don't; it works well enough for what it does (as H.G. has elaborated on). More that we were discussing a previous commenter's proposal to extend it using non‐ASCII.

I'd still be tempted to hold out a degree of openness for exactly the purpose I mentioned: 3D (let alone 4D) or unusual (hyperbolic, say — I've been musing over an actual Regular Octagonal Chess to match Frolov's approximation) boards where the existing letters would all apply but more would be necessary to cover the extra moves. Though one might equally argue that at that point it's far enough from the familiar that Betza is somewhat out of its depth anyway.

And while hexagonal boards may be in scope for the ID, I imagine 3D and hyperbolic boards are far from it ;‌)

you'd (apparently) lean toward using ß for Sexton, while I'd use it for Switchback

We're technically not contradicting each other; I was using capital ⟨⟩, as is usual for atoms, whereas Switchback, whilst really something that XBetza would tend to spell out explicitly, is definitely small ⟨ß⟩ material

under my suggestion, I could define Þ to represent the Rose's movement path (possibly with a line something like def Þ = qN -- not just a character replacement, but a definition of a movement path).

Strictly speaking a path‐and‐mode model is not quite what XBetza does; rather it decribes moves in stages.

Which is, to be fair, in line with how Betza thought; the ‘Ferz‐then‐Cannon’ of his Bent Riders article comes easily to XBetza whereas a path‐and‐mode description thereof is cumbersome at best. Conversely path‐and‐mode describes the contrasted ‘Bent Cannon’ much more naturally.

I may be wrong, but trying to get XBetza to manipulate a Rose path in that way once it's been defined might be more convoluted than it appears


Bob Greenwade wrote on Thu, Mar 14 10:44 PM UTC in reply to Daniel Zacharias from 10:31 PM:

The first part wouldn't even need the brackets; mqN works perfectly well. It's trying to get caib[qN] to work that would be the challenge.


Daniel Zacharias wrote on Thu, Mar 14 10:31 PM UTC in reply to Bob Greenwade from 04:18 PM:

So, under my suggestion, I could define Þ to represent the Rose's movement path (possibly with a line something like def Þ = qN -- not just a character replacement, but a definition of a movement path). Then the Rifle Rose could be mÞcaibÞ.

If a bracketed move could be treated as a path, this could be m[qN]caib[qN]


Bob Greenwade wrote on Thu, Mar 14 04:20 PM UTC in reply to H. G. Muller from 04:07 PM:

But the bracket notation for describing multi-leg moves is much more intuitive, and hardly any less intuitive than the original Betza notation was for single-leg moves.

I agree with this completely. If I can figure out a move using BBetza, even if the XBetza is technically simpler, I'll do that.


Bob Greenwade wrote on Thu, Mar 14 04:18 PM UTC in reply to Fergus Duniho from 03:34 PM:

One question you should ask yourself is why you want to expand xBetza.

My answer is: I don't. The use of an extended character set, as I'm suggesting it, would appear on a case by case basis, be programmed by the designer of the variant, and only affect that game's Interactive Diagram.

To clarify an earlier illustration. Normally, qN is more than sufficient to define a Rose, and XBetza is good enough to handle most variations that I can think of. But then there's the "Rifle Rose," which can not only move like a Rose, but make a rifle capture along the same path. There's not really any good way to do that in XBetza.

So, under my suggestion, I could define Þ to represent the Rose's movement path (possibly with a line something like def Þ = qN -- not just a character replacement, but a definition of a movement path). Then the Rifle Rose could be mÞcaibÞ. The definition wouldn't affect anything outside that one specific Interactive Diagram; other users could use a different character for the Rose, use Þ for a different function, or both. The Þ wouldn't even have to appear outside the ID, though I think that a brief explanation in the text would be the polite thing to do.

Addendum: It's already possible (though not generally a good idea) to use any Unicode character for single-character piece ID codes. I haven't experimented yet with using those in captureMatrix and similar functions, but if they work there then that's one problem (provisionally) solved -- though I'd still advise folks to avoid it when possible.


💡📝H. G. Muller wrote on Thu, Mar 14 04:07 PM UTC in reply to Fergus Duniho from 03:34 PM:

Actually I agree that XBetza has become too obfuscated, and that it has grown that way because of its use as move definition in the Interactive Diagram, where there was demand for pieces with ever more complex moves. But the bracket notation for describing multi-leg moves is much more intuitive, and hardly any less intuitive than the original Betza notation was for single-leg moves.

But it should be kept in mind that the complex, hard-to-understand descriptions in practice hardly ever occur. The overwhelming majority of variants never gets any further than symmetric slider-leaper compounds, which are dead simple. Personally I think it is much easier to read or write BN rather than "bishop-knight compound' all the time. It is certainly moer easy for a computer to understand than colloquial English, and is not beyond the understanding of most people. (While programming languages are.) The reason Betza's funny notation has become so popular is mainly that although it potentially can be complex, the cases needed in practice are quite simple.

BTW, the Play-Test Applet already contains a Betza-to-English converter, even though it is not always perfect yet.


🕸Fergus Duniho wrote on Thu, Mar 14 03:34 PM UTC in reply to Bn Em from 11:56 AM:

Clearly one argument against expanding beyond ASCII would be disagreement over which letters to include! My preference would be where possible to stick to non‐precombined characters; thus we'd both be ok with ⟨Þ⟩ or ⟨Æ⟩, but I'd avoid ⟨Š⟩ and ⟨Ä⟩ whereas you'd (presumably) take exception to ⟨Ƿ⟩ or ⟨Ꞵ⟩ (assuming those even show up for you).

When Ralph Betza first came up with his funny notation, I believe the purpose was for communicating piece movement capabilities in a brief notation that could be easily read by another person. In contrast, H. G. Muller's xBetza notation has become more of a programming language, and it already comes across as an obfuscated one at that. Personally, I don't use funny notation or xBetza, because it is already too complicated. I prefer to use English for communicating with other people or a full-fledged programming language, such as GAME Code, for programming how a piece moves. One question you should ask yourself is why you want to expand xBetza. If it's to easily communicate more types of piece movement to people, I think it's going to reach a smaller and smaller audience as you add more characters to it. If it is to more easily program types of movement not already supported, I think it would work better to allow the use of longer names through some kind of bracketing, sort of like Game Courier's FEN allows longer names within braces.


Bob Greenwade wrote on Thu, Mar 14 03:07 PM UTC in reply to H. G. Muller from 12:56 PM:

I have thought about supporting hexagonal boards in the Interactive Diagram.

The way you describe it could be a handy stopgap, but I'd be more in favor of something specifically made for hex boards, treating W as a move to an adjacent hex, F as a move to a corner-adjacent hex*, and the rest as extensions thereof. The directional modifiers would be the only truly hard bit to figure out, I think, especially with t and w being the only unused lower-case letters for adding, but I suspect that a bit of brainstorming could work something out.

About castlings: one can of course think up any sort of crazy move, and present it as a castling option.

Well, my description of gO was just a random thought, taking the notation to its logical description, and not as something that would necessarily be useful. If the "cascading castle" you describe in the next paragraph after the above seems like a more reasonable (as well as more useful) interpretation, then I say you should go for it -- it's something that I could imagine using in a variant (though I'd be more likely to want a as its notation).

*An awful description, I'm sure, but I think you know what I mean there.


Bob Greenwade wrote on Thu, Mar 14 02:41 PM UTC in reply to Bn Em from 11:56 AM:

Clearly one argument against expanding beyond ASCII would be disagreement over which letters to include!

This (and what follows) is much of why I argue for using only the ANSI extensions, and even those only for custom (that is, user-defined) atoms. I've already made some private notes for the use of Ä, Ç, Ê, Ë, Ñ, Ø, Ô, Š, Þ, Ü, Ž, and ß (as well as V), some of which I've shared already, but your uses of those characters on an ID could (and probably would) be different from mine.

And as H.G. points out, notation for hexagonal, triangular, and 3D (or more) layouts could (and probably should) start from scratch for meanings. Even so, I can imagine running out of atom letters quite quickly (especially in the last case), and might even overwhelm the extra characters of ANSI, in which case I could see expanding to Greek letters or even Latin Unicode.

...whereas you'd (presumably) take exception to ⟨Ƿ⟩ or ⟨⟩ (assuming those even show up for you).

Those did show up, and you already showed one example of where different people would use the same letter for different things: you'd (apparently) lean toward using ß for Sexton, while I'd use it for Switchback. And we could; I'm not in favor of standardizing the ANSI characters, but rather making them available for use when user-defined atoms are implemented (and I'm not expecting that before the end of next year at best).


💡📝H. G. Muller wrote on Thu, Mar 14 12:56 PM UTC in reply to Bn Em from 11:56 AM:

The idea of a fixed move that can be described by a notation implies a board with regular tiling. Such a tiling can have other connectivity than the usual 8-neighbor square-cell topology, e.g. hexagons or triangles. But these could have their own, completely independent system of atoms and directions, reusing the available letters for their own purposes.

I have thought about supporting hexagonal boards in the Interactive Diagram. This could be done by representing the board as a table with a column width half the piece-mage size, and give every table cell a colspan="2", in a masonic pattern. That would distort the board to a parallellogram. A numerical parameter hex=N could then specify how large a triangle to cut off at the acute corners. The board could then be displayed without border lines and transparent square shade, so that a user-supplied whole-board image with hexagons could be put up as background for the entire table. This would purely be a layout issue; the rest of the I.D. would know nothing about it. In particular, the moves of the pieces would have to be described in the normal Betza notation as if the pieces were moving on the unslanted board. E.g. a hexagonal Rook would be flbrvvssQ.

About castlings: one can of course think up any sort of crazy move, and present it as a castling option. But in orthodox Chess castling exists to fulfil a real need, rather than the desire to also have a move that relocates two pieces at once. The point is to provide a way to get your King to safety without trapping your Rook, and without having to break the Pawn shield. Sandwiching a piece between your Rook and King doesn't seem to serve a real purpose. If the piece could easily leave you could have done that before castling, and if not than it is still semi-trapped.

A more sensible novel form of castling would be where multiple piece end up at the other side of the King. E.g. when the piece next to the Rook would be a Moa ([F-W]), conventional castling is not up to the task. You would need a castling that moves the Rook to f1, and the Moa to e1, upon castling to g1 on 8x8. Of course you could argue that this is a defect of the start position, and could better be solved by choosing a setup that had a jumping piece on b1/g1.


Bn Em wrote on Thu, Mar 14 11:56 AM UTC in reply to Bob Greenwade from Wed Feb 28 03:48 PM:

Clearly one argument against expanding beyond ASCII would be disagreement over which letters to include! My preference would be where possible to stick to non‐precombined characters; thus we'd both be ok with ⟨Þ⟩ or ⟨Æ⟩, but I'd avoid ⟨Š⟩ and ⟨Ä⟩ whereas you'd (presumably) take exception to ⟨Ƿ⟩ or ⟨⟩ (assuming those even show up for you).

One valid use for beyond‐ASCII letters imo would be expanding Betza beyond the square board; we have few enough capitals left that e.g. ⟨⟩ for ‘ⅎiceroy’ or ⟨⟩ for ‘ßexton’ (both of course Gilmanese) might be in order. And since the ID doesn't do non‐square boards (except through hacks as for Chess66) it wouldn't even need to worry about them. Likewise the non‐square directional qualifiers (I'm maybe grasping at straws a little with ⟨ɂ⟩ and ⟨ƿ⟩ for ‘up’ and ‘doǷn’, but non‐ASCII letters cover an odd sound space…)

There is no such thing as a 'regular keyboard'

Especially when you have people like me who (heavily) customise their layouts; all the characters I've just typed (except the quotation) are accessible for me without copy–pasting


Bob Greenwade wrote on Thu, Mar 7 04:37 PM UTC:

Useless tip:

vsQ = B
vsK = F
vvssQ = R
vvssK
= W

(Well, it's probably completely useless right now, but it or something similar might become useful in the future.)


Bob Greenwade wrote on Wed, Mar 6 04:43 PM UTC in reply to Bob Greenwade from Mon Mar 4 05:46 PM:

I have an idea for something gO could do, but I'm not sure it'd be used at all (including by me) so I'll leave it alone for now.

Mostly just for the heck of it (but also in case anyone's curious, or might find it useful): My idea was that gO could represent a sort of "grasshop castle" with a single piece between the King and Rook (or whatever the two pieces are), with each of the two taking position on the other side of the intervening piece. (Of course the full notation would be isgO, but the g is the significant part).

It's probably too much trouble to actually code, especially since (as I already stated) I'm not sure that even I would actually use it; I just thought I'd share the idea.


Bob Greenwade wrote on Mon, Mar 4 05:46 PM UTC in reply to H. G. Muller from 05:32 PM:

Good answer, and good info.

I have an idea for something gO could do, but I'm not sure it'd be used at all (including by me) so I'll leave it alone for now.


💡📝H. G. Muller wrote on Mon, Mar 4 05:32 PM UTC in reply to Bob Greenwade from 05:05 PM:

would pO (with other appropriate modifiers, of course) allow castling with an intervening piece?

Sort of. I chose that as the notation of 'Fast Castling', which allows the King to jump over arbitrarily many pieces or attacked squares. The Rook would then move to the King's square of origin, though. So it is not normal castling that can hop.

The O atom is treated somewhat differently from other atoms. (E.g. the range indicator specifies the exact number of King steps, not the maximum as ranges normally do.) It had to, for making the combinations useful.


25 comments displayed

Later Reverse Order EarlierEarliest

Permalink to the exact comments currently displayed.