Comments by HGMuller

What I don't fully understand is why you stress that it should be HTML and
JavaScript. Perhaps because I don't fully understand how you envision this
to be used.

When I encounter a PGN game somewhere (as text on a web page, or as a
downloadable .pgn file), I always view it with WinBoard (by pasting it in,
or loading it from the downloaded file). Then you have all the
functionality you say: you can step through the game, while viewing the
comments, edit the game by adding or deleting moves at the end, add
comments to it, or edit the exsting comments, save the (edited) game on
file, or copy it (or the position) to the clipboard, save positions as a
diagram on a bitmap file.

Plus you can do more, as it is also possible to have an engine analyze the
positions in the game, and show its scores and PVs in a separate window. I
always have a WinBoard shortcut on my desktop to quickly start it up when I
need to view PGN.

I don't see how HTML would add anything to this. The reason I made the
JavaScript viewer was to allow people to follow games live with a browser.
It was never meant as an analysis tool.

BTW, the castling tag is not really needed, absense of castling could
simply be indicated in the FEN for the initial position.

Hmm, I am starting to doubt that the Guanaco is anywhere near a Bishop in
value. In the match of two Guanacos vs two Knights the Knights lead by 80%.
Strange thing is that two Llamas vs one Knight seems to go towards a very
clear victory for the Llamas (64%, which suggests a difference of the order
of a Pawn). All this after a mere 100-150 games, so with a sizable error
bars. But these results would put a Guanaco quite close to a Llama, which
is a bit strange, as it is clearly upward compatible with it.

Perhaps I should start with a test of two Guanacos against two Llamas, (say
as Knight replacements), to get a direct measure of how much the difference
between the two really is. It might be that the distant non-captures are
pretty useless. Thee are only few squares from which you can actually make
them on 8x8, and perhaps the Llama is already fast enough.

One thing I can confirm straight away, though: Both two Llamas and two
Alpacas make a generally won end-game. (Maximum distance to mate 43 or
51 moves, respectively.)

Yes, it seems I have to go 'back to basics', and first make sure that the
program handles the pieces well. I was running the test where the Guanaco
did so poorly with programmed-in values that had the Guanaco worth slightly
less than a Knight (240 vs 259 in the peculiar micro-Max internal units
that have B=296). So the problem you mention could not have occurred.

I did not program the Guanaco as a piece that has to be centralized,
however. Fairy-Max knows two kind of pieces, those that are lightly) drawn
to the center (Kings, Knights and Bishops), and those that move neutrally
over the board (which works better for Rooks and Queens). I programmed the
Guanaco as belonging to the latter group, because I figurered that its rider
moves woud make it behave like a Rook, while the Llama was obviously short
range and not very valuable, so the center was the obvious place for that.
But perhaps the Guanaco has to be centralized to perform well. This can
matter a lot: for the Lion (FWADN) I initially figured that it was too
valuable to centralize it (it would only be chased), but giving the program
a drive to centralize upped its value by nearly half a Pawn.

So the first thing I will do now (last night's tests were spoiled by
auto-updates...) is to test a symmetric position with Guanaco-for-Knight
substitution, between two differently configured versions of Fairy-Max, one
that centralizes the Guanaco, the other that doesn't. (And perhaps repeat
it with Guanaco-for-Bishop substtutions, or GG for BN.) This should tell me
if a Guanaco gets you more when it is centralized.

After that I will do a a Guanaco vs Llama test, between idenical engines
that handle the Guanaco in the way that proved best. In this test I will
configure the Guanaco only very slightly above the Llama in value. We know
the Guanaco must be better. This should result in an initial empirical
Guanaco-Llama difference. The test should then be repeated with this value
programmed in, for confirmation.

One question: would the end-game you show not be equally won when black
had a Llama rather than a Guanaco? That it is won might be due more to
thefact that black has an extra Pawn, while white has two very awkward
Pawns (one backward, one isolated) than to the Guanaco being so powerful.

This is starting to get very mysterious. Whatever I do, it seems impossible
to create conditions where Guanacos convincingly beat Llamas, between equal
programs. The scores always converge around 51-53% in favor of the Llamas,
so far. There is an error of around 3-4% on this, as it was all done with
about 100 games, but still... It is totally ridiculous outcome, as the
Guanaco is obviously upward compatible.

What I did was this: First I established that it is a much better strategy
to centralize Guanacos than to leave them roam the board neutrally: A
version that centralizes wins symmetric positions where each side has two
Guanacos (replacing the Knights) very convincingly (66% score in 100
games).

Nevertheless, with this better Guanaco handling, the score of Guanacos
against Llamas (between identical programs) remained around 50%, like it
was with the poor Guanaco handling. This is not unusual: The fact that the
program having the Guanacos knows that they are better in the center is
largely offset by the fact that its opponent now knows this too, and tries
to keep them out of the center. I did this test with a value of 240 for
Guanaco and 180 for Llama (on a scale Bishop = 296).

So my first thought was that the high programmed value of the Guanaco was
hindering its proper use, by making the program too scared to risk it being
traded for other material. So I repeated the test with rogrammed values 180
and 190. But after 100 games the Llamas now lead there by 52%.

The only thing I can think off at the moment to explain this is that the
extra Guanaco moves (compared to the Llama) are nearly useless, but that
the fact that they are searched increases the branching ratio of the search
tree, reducing its depth. The side having the Guanacos suffers more from
this than its opponent, as at odd ply depth it searches one more level in
the tree with Guanaco moves than the program with the Llamas. But I cannot
imagine that this effect is very big. (There are not that many distant
Guanaco moves, compared to total moves in a typical positon.)

Anyway, it seems that the Guanaco hardly offers any advantage over the
Llama. Which is a bit surprising. I also did another test with to Guanacos
as Knight replacements on one side, between Guanaco-centtralizing engines,
and the Guanacos get clobbered by ~73% so far.
I will let these test runs overnight to get somewhat better statistics,
but everything so far points to nearly equal Guanaco and Llama value, both
significantly weaker than a Knight.

First, I have to apologize for creating confusion: I mixed up pieces, and
everywhere in my previous posts where I said Llama, I actually meant Alpaca
(Betza WmD). So I have been comparing Alpaca with Guanaco (Betza WmDD). And
it is obvious the Guanaca must be the stronger of the two, as it is fully
upward compatible with the Alpaca. I did not do any tests wit the Llama
(DmW) yet.

[I wll probbaly edit my previous posts to correct this error, soon.]

About the Lion: you are right, I had nearly forgotten about this peculiar
artifact. Now that you reminded me I remember: The Lion seemed to get
stronger by deleting some of its backward moves! But this was only when I
programmed it as a neutrally moving piece, and could be well understood in
this context: if an assymmetric piece moves randomly over the board (i.e.
each move is chosen with equal probbility) it tends to gravitate in the
direction with the most moves. (Actually towards the center of gravity of
its footprint.) So the Lion with fewer backward moves had a net forward
drive, which turned out much more important for its impact on the game than
a few extra means of retreating. (As it already had so many of those.)

But this effect disappeared entirely when I programmed the Lion as a piece
that should be centralized. Then both the nomal Lion (FWADN) and the one
missing a few backward move got much stronger, but the latter was clearly
weaker than the former, as it should. So articacts like this can only have
an impact if the original strategy fr using the piece s far from optimum,
and not very stable (i.e. easily affected by minor issues.)

About the center: Centralization is something different from mobility.
(Although the two happen to correlate in practice.) The reasons why it is
good to centralize pieces are:
1) Pieces like B can attack the opponent's lines in two places, that he
might not be able to simultaneously defend with non-cenralized pieces.
2) Short-range pieces have their worst-case travel time to any place on
the board minimized.
3) Pieces for which (1) or (2) do not apply can attack and defend squares
in the center to chase away or create safe squares for pieces for which it
does.
None of these is related to the number of moves of the pieces per se: a
Wazir only loses moves (and just a sngle one) at the edge of the board, but
it is far better positioned on e4 than on b2. Pawns in the center are
important because of (3). I guess the Guanaco should be centralized also
because of (3), (with only a single forward direction, (1) does not apply,
and because of its rider moves distance (2) plays no role either), which I
initially overlooked.

Btw, it seems we simply were unlucky: where after 100 games the Guanaco
vs. alpaca was only at 48%, after 250 games it had recovered to a 56% lead
for the Guanacos. I will let it run to 400 games (2% statistical error).
Nevertheless, a 6% advantage for two Guanacos over two Alpacas is not very
impressive; it is not even half a Pawn. (I will repeat the test with the
f-pawn deleted for the Guanacos, to get a precise interpolation.) So it
seems the value difference between a single Guanaco and Alpaca is at most a
quarter Pawn.

I agree that it is important where the opponent is. If he would huddle with
all its pieces in one corner, (and there is no need to defend the back rank
in the other corner against promotions), the usefulness of being in the
center deminishes. There are some default assumptions here, and one of
those is that the opponent's pieces will be stretched out along the entire
back rank on his side of the board. In the end-game that assumption might
fail. If both sides only have Pawns on the King side (say on f-, g-, and
h-file) plus Knights and Bishops, there is absolutely no point being in the
center.

I would think g4 indeed a better square for a Wazir than e2, because it is
closer to g7, and not further from b7. This is only from the point of view
of attacking, though; A Wazir can also be useful as a defender, and that
might be a reason to keep it on g2 (with Kg1, and Pawns on f2, g3, h2). But
that pertains to King Safety, which is yet another, independent evaluation
term.

Mats: 'But it's to few games. However, it could be a program problem.
Maybe Zillions is intelligent enough to handle this piece well.'

Well, 3.5-0.5 is indeed far to few games to conclude anything. It could
easily occur in a match between two exactly equal opponents if one of them
is slightly lucky (e.g. because his opponent blunders away a single win).

I am at 366 games now, and the Guanacas lead by 57% over the Alpacas. When
I reach 400 games there, I will delete the f-pawn of the Guanaca side, and
see how they do then. (The Alpacas should win then by a similar amount.)
Two Knights vs two Guanacos is at about 250 games now, and the Knights lead
by 77%.

Intelligence is usually not in the vocabulary of Chess programs. It is all
brute search power, going through millions of positions with a very
simplistic evaluation. (Counting wood or moves.) Especially for a
generalist program like Zillions, that has no specific guidelines
programmed in for the Guanaco for sure.

I don't believe that handling Knights (or Alpacas, for that matter)
requires less intelligence than handling Guanacas. I don't believe that
Zillions would be any better at handling any specific piece than Fairy-Max.
Fairy-Max is only a very simple Chess program, but despite its complete
lack of programmed knowledge (except the piece values) it plays
surprisingly strong in normal Chess, dominating over many engines that are
stuffed with Chess-specific knowledge. Apparently it does not need any
knowledge to handle its pieces intelligently enough to win; plain search is
good enough, even in the end-game.

From what people told me, I don't think Zillions would be a match for
Fairy-Max in Chess variants with FIDE-like Pawns that they can both play. I
have not tested this myself, of course, as Zillions is commercial software
that I don't have. So it is just based on what people that do have
Zillions told me.

I understand that there is an adapter that allows WinBoard engines to play
in the Zillions GUI. Isn't it possible to play Fairy-Max against Zillions
automatically, that way? Then we could handicap one of them by time odds
until they play equally strong in normall Chess, and then add or substitute
Guanacas on both sides, to see if this breaks the equivalence because one
side handles the Guanacas 'more intelligently' than the other.

The 2 Guanacas in the end beat the 2 Alpacas by 56.3% in 404 games. I now
gave them an additional Pawn odds for a new 400-game run. As predicted from
the previous result, the Guanacas seem to be losing that substantially.

I stopped the 2 Knights vs 2 Guanacas match after 300 gmes, with the
Knights leading by 77.8%. Such an extremely unbalanced result cannot really
tell me anything quatitative, So it makes no sense to try to reduce the
error from 2.5% to 2%. In stead I started a match of 2 Knights vs 3
Alpacas, where I put the third Alpaca on d2,e2,d7 or e7, advancing the
corresponding Pawn by 1 square. e.g.

rnbqkbnr/pppppppp/8/8/8/4P3/PPPPAPPP/RABQKBAR w KQkq - 0 1

where A = Alpaca. This seems to go pretty even (but only 20 games so far,
so can still easily be anything between 35% and 65%).

I remember I did some divergent pieces sometime ago (in particular mNcK,
mKcN, mQcN and mNcQ), and I thought I posted the rsults at CVP. But I
don't remember where, and I cannot find it. What I recall was that mQcN
was 450 and mNcQ 750, when N=325 and Q=950. I never did mQcK and mKcQ, but
snce K and N are pretty close in value, one might expect nearly the same.
Now R is about half a Q, and W is about half a K, so it does not seem that
silly if mRcW would be about half a mQcK, which would be about equal to
mQcN = 450. That would put mRcW around 225. Now the Guanaca is very similar
to mRcW: its lacks the odd-stride distant non-captures, but as a
compensation it jumps, and so it cannot be blocked on these odd-distance
squares. So actually something around 225 would seem a quite reasonable
value for something like the Guanaco.

Mats: 'I don't understand why you haven't purchased this wonderful software. It's only $20.'

I guess the main point is that I aready have my own programs, which I
consider better, and for which I don't have to pay anything. That does not
only pertain to playing strength, but also to the things it can do. E.g.
automated self play. I suppose there is a reason why you only played 4
games with Zillions to play-test the Guanaca, and turn to me to play a few
thousand, in stead of having Zillions do that?

Another issue with Zillions is that it does not support a standard
interface for playing external opponents. I know there is an adapter that
allows WinBoard Chess engines to play in the Zillions GUI. But can the WB
engine play againt the native Zillions AI, in that case? Can two native
Zillions AIs (such as one of your hand-tuned versions against the standard
one) even be played against each other, to optimize the tuning? Does the
WinBoard-to-Zillions adapter work for any variant besides normal Chess?

In short, based on the information I have, WinBoard + Fairy-Max are far
superior to Zillions, and they are free. That Fairy-Max has limitations in
the piece types that can be programmed into it through its .ini file could
be a problem for non-programmer users that are limited to altering the
piece definitions in that .ini file. But it isn't to me: if I would be
really interested in a particular piece falling outside the usual parameter
range, I would simply add a few lines in the C code of Fairy-Max to make it
support such pieces (or special winning conditions). This is what I did to
make a Xiangqi version of Fairy-Max (MaxQi), or for implementing the
Shatranj baring rule (Shamax).

Did you ever download Fairy-Max? That is only $0...

On the main topic: Some 'half-time standings': 2 Alpaca + Pawn are
leading 65% over 2 Guanaco. (Which is more than I would have expected;
usually deleting a Pawn on 8x8 only swings the result by 15-18%). 2 Knights
are leading 55% over 3 Alpacas.

Zillions cannot be compared to anything else, because of its amazing
geneality. But that does not mean that any particular thing Zillions does
cannot be done better by other means.

Zillions is basically a programming language, and so it can do anything.
But C is also a programming language, and it can also do anything. Although
some pieces are too complicated to handle for Fairy-Max at the level of the
configuration (.ini) file, because I only provided for true Chess pieces
(i.e. moving from one square to another in a translation-invariant pattern,
capturing by replacement). Side effects are rare and too specific to
generalize them efficiently. So they cannot be implemented by enabling pre-cooked 
options from the .ini file.

But that does not mean I could not handle such pieces if I wanted to. It
only means that in such a case I would have to handle them at the C level.
Being the author of Fairy-Max, it is very easy for me to add the necessary
code to implement peculiar properties at the C level. I would have little
difficulty to use pieces like BodyGuard or Coordinator in a Fairy-Max
derivative, like I have no problem limiting Kings and Guards to the palace
in a Fairy-Max derivative (MaxQi) that plays Xiangqi. It is very
questionable if this would take more effort than describing the piece in
ZRF. 

How I would do that, would depend on the case at hand. having to think
about it would allow me to choose an efficient implementation. For the
BodyGuard I could for instance test all surrounding squares on the presence
of an enemy BodyGuard, and abort the ray scan if there is one. that would
probably still leave Fairy-Max faster (in searched positions per second)
than Zillions, which always has to test for who knows what strange
propertis of pieces. But really efficient implementation would add the
lines

position[piece] = toSquare;
position[piece] = fromSquare;
if(neighbor[toSquare - position[32 - color + BODYGUARD] + 140]) break;

in the code for MakeMove, UnMakeMove and the ray scan of the move
generator, respectively, plus an initialized table

char neighbor[280] = {
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
0,0,0,0,0,0,0,0,0,0,0,1,1,1,0,0,
0,0,0,0,0,0,0,0,0,0,0,1,0,1,0,0,
0,0,0,0,0,0,0,0,0,0,0,1,1,1
};

Well, big deal, 3 lines of code and a trivial table. I doubt if you have
to tell Zillions less than that to implement the stimying effect of a
BodyGuard.

I don't understand your negativism towards brute-force tree searching; I
am sure that this also is exacly how Zillions comes up with its moves.
Except that the need to be general slows it down, so that it searches less
deep. And that means it plays on the average weaker moves. Deep searching
has proven the way to winning Chess. Why you would prefer to have an entity
that plays like crap just to be able to say that it was not a 'bean
counter' escapes me.

I think you misunderstand how engines work. Tree search is simply their way
to make plan. That is by trial and error, discarding what does not work,
rather than by constructive reasoning selectively producing only that which
does work. But the result is exactly the same, and you should not be able
to see the difference by watching it play.

For Chess there are many different engines, with many different
'personalities'. Yet the search algorithm of every engine is almost
exactly te same. It is the evaluation that creates the personality. But the
search is necessary to distill strategic traits from  transient 'noise'
in the evaluation, and thus make the evaluation a meaningful guiding
principle. E.g. like havinga passed Pawn on the 7th rank, (in most cases
very good), which happens to be untenable and will be lost in 2 moves,
making that you are simply a Pawn behind.

If engines storm the opponent's King fortress with Pawns, it is because
their evaluation has some non-linear term in its King Safety, which
penalizes a King as the (say) square of the number of enemy Pawns close to
it. They don't have the slightest idea that a checkmate might likely be
the result. It is the programmer of the evaluation function that new that,
and new that by the time the engine has the Pawns in place, it will likely
see a way to push them that breaks down the opponent's fortress and leads
to mate within its search depth.

The problem with very good engines like Rybka or Fritz is that their
'plans' are completely beyond us mortals, so that we cannot recognize
them as such. While the plans we would make in the same position ar in fact
hopelessly futile attempts that they easily refute and blow to pieces. This
is why it is much more fun to watch games between 'weaker' engines than
Fritz.

Btw, the 3 Alpaca vs 2 Knights match ended in 47.9% after 402 games. This
is really within the margin for equality, so it seem that an Alpaca is
nearly exactly 2/3 of a Knight. (i.e. 215 in Kaufman units, which has
N=325.)

The 2 Guanacos vs 2 Alpacas + Pawn was lost by the Guanacas with only a
37.4% score (434 games). This confirms a Guanaco is worth a lot less than
an Alpaca + 0.5 Pawn, perhaps 235.

I am now doing 3 Guanaco vs 2 Knights and 2 Alpacas vs 2 Llamas (all as
Knight replacements).

What you describe is purely a matter of evaluation. Such Rook manouevres
(when they are pointless) is typically what you get when you award attacks
on the King's Pawn shield by evaluation points. Because that makes
attacking these pawns a goal in itself, and it will do it even when there
is no follow up (i.e. when the plan was pointless). Without such evaluation
award, it would only go for the manouevre if it did have a follow up that
would be awarded in the evaluation (e.g. breaking down the Pawn shield,
exposing the enemy King) AND it would reach the depth to see it. Awarding
the mere attack on the Pawn shield makes that it will find the devastating
King attack at much lower depth (and thus much further in advance at the
same depth). But it has the problem that it also can backfire, when the
plan is pointless, and would isolate a Rook that was needed badly in
defense on the Queen side (e.g. to stop a passer break through). In this
case it just leads to bad Chess.

This is exactly the problem that I am facing in my new Xiangqi engine,
HaQiKi D. To make it survive the middle-game against strong opponents, it
is essential that it gives high evaluation points for Horses and Pawns
appearing close to the enemy Palace. If it doesn't, it allows the opponent
to amass his material for an attack, until it suddenly sees that there is a
mate within the horizon in every branch, because its strategic position is so
bad that there is no cure.

But it also backfires badly: in end-games where it is behind, e.g. HaQiKi
D has 2A+H, and the opponent has 2A+2E+2H, it might be able to draw by
defending with 2A+H against 2H. (The opponent cannot use his 2A and 2E in
attack.) Trading H vs H would be enough, as 2A vs H is a theoretical draw.


But is loses all such games: his own H is drawn to the opponent's palace
like a moth to a flame, in a completely futile attack on an impenetrable
fortress, defended by 2A+2E, where it could not threaten a checkmate even
against a bare King. And then of course his own King is toast, as 2A is no
defense against 2H. 

And then it makes it even worse: in 'remedy' of attacks by the 2H on its
own defending A, it start to counter-attack the opponent A or E, so that
they are traded. Effectively, this indirect trade is like allowing the
opponent A or E to cross the river and join in the attack, breaking don
further what minimal defense there was. (After trading one A, the game is
even lost even if you could trade Horses, as A vs. H is a theortical loss.)
Incredibly stupid! Virtually every end-game from a slightly inferior
position is lost by HaQiKi D this way.

So allocating material to futile plans is not free: it is in fact losing
Chess. Which means that it will disappear (in this simple
Human-recognizable form) on deeper search, when the search corrects the
initial misevaluation. I.e. when it can see the checkmate can no longer be
avoided within the horizon after trading A, or the opponent's promotion
cannot be stopped after isolating your Rook in front of your f,g,h-Pawns.
If there is any fun to be had watching the engine make such futile
attempts, it is only the fun of pitying the stupidity of your opponent when
he does this.

Well, unless you secretly changed topics, we are not discussing AI here at all. We
were discussing Zillions. And Zillions works exactly as I decribed. Even
Humans think far deeper than 4 ply; without that it is not possible to play
any decent Chess, except perhaps at the level of a 6-year-old.

But my main criticism still stands, and is totally independent of any mode
of move productions: you admire moves that are futile, and call them 'a
plan'. While in fact they are just bad Chess, by an entity that does not
properly know what it is doing. You loath 'bean counters' for no apparent
reason other than that they play good Chess.

Well, for deriving piece values I need Chess of a reasonable quality, and
the better the engine, the faster it can play to deliver that quality. If
Zillions needs 30 min per game to reach the same quality as Fairy-Max has at
1 min per game, a 400-game run that I do in a day with Fairy-Max would take
a month with Zillions. That is not doable, as you need mny such runs to
derive the value of a single piece.

The 3 Guanacas beat 2 Knights by 54.8%. Again spectacularly little better
than 3 Alpacas. The small difference between these pieces continues to
amaze me. I should do more tests with divergent pieces, to see if this is a
general trait of non-capture slider moves.

2 Alpaca vs 2 Llamas ended at 50.6%. I forgot for whom, but that does not
really matter as this is equality to far within the resolution of the
test.

I will stop this testing now for some time, as I have to test the opening
book for my engine HaQiKi D, to get it ready in time for the Computer
Olympiad in Pamplona (May 10-18).

You have to be careful with that kind of reasoning. If the Guanaca had more
captures, it might very wel be worth more than a light piece intrinsically,
and you would not even want to trade it for a light piece. 

There are some pieces for which your reasoning works, e.g. the Camel on an
8x8 board. this is basically a useless piece in the end-game; the side that
has it will almost always lose it without compensation. The opening value
seems to be purely derived by its forking power on a densely populated
board allowing it to be trded for something else. (In the end-game you can
often not even trad it for a Pawn...)

The intrinsic value of a piece is usually determined by how well it
cooperates with the King in positions with several Pawns, to protect its
own Pawns and support their advance, and to gobble up the opponent's and
stop their advance. This is how most Chess games end, so a piece that does
well there has a really large impact on the average performance. Despite
its fairly large number of posible targets, the Camel is totally inept in
this respect: the targets are non-contiguous and mostly far apart, and if
they are not actually off board, they are still too far away for useful
manouevring, once there are ony very few 'centers of activity'. Hoppers
might also best be gotten rid of before the late end-game, although a
Cannon does remain dangerous even with the tiniest supporting material
(e.g Cannon + Ferz makes a won end-game against a bare King).
Grasshoppers definitely get useless very quickly.

But the Guanaca is not particularly bad against Pawns. So I expect most of
its value is intrinsic, and making it more powerful by adding moves would
up its intrinsic value faster than the ease to trade it for B or N.

Oh sorry, I did not get that both sides can chose between K or Q. Then
indeed there are 8 possibilities, 64 in total.

I guess the problem is similar to that in Shogi and Crazyhouse. I am not
sure these games even have 50-move rules.

Hmm, this seems a non-standard way to recognize FRC games. When I load the game in WinBoard (after correcting the single quotes back to double quotes, orf course) it does not recognize it as FRC, and complains about the O-O-O. When I set WinBoard to FRC before loading the game it eats it, but when I then safe it again the tags look like:

[Event 'Placement Chess, Rapid']
[Site '?']
[Date '?']
[Round '-']
[White 'Tascbase 2.1/The King']
[Black 'Tascbase 2.1/The King']
[Result '*']
[Variant 'fischerandom']
[FEN 'rnkbbqnr/pppppppp/8/8/8/8/PPPPPPPP/RNKBBQNR w HAha - 0 1']
[SetUp '1']

The Variant tag is intended to indicate the variant and imply the castling rules. This seems a much more user-friendly way than encoding the variant as some obscure number. e.g. what number to use for Xiangqi?

Note that WinBoard would recognize many other names in the variant tag as FRC as well. Such as 'FRC' or 'Chess960' (or 'w/22', as it is called on ICC). Perhaps I should change the default name (which it prints) to 'Chess960', as this seems to be the name that is winning out amongst players of this variant, now that Bobby Fischer is not so popular anymore.

That probably explains it; I don't think that at that time a standard for FRC had emerged.

Anyway, the following system seems a very satisfactory way to handle drops, substitutions and swaps in SAN, as SAN makes distinction between captures and non-captures:

non-capture to empty square (e.g. Kf1): normal move
capture to occupied square (e.g. Kxf1): normal capture, or capture of own pieces
non-capture to occupied square (e.g. Kf1): swap mentioned piece with whatever was on the to-square
drop to empty squuare (e.g. N@e4): drop from holdings
drop to occupied square (e.g. N@e4): substitution, whatever was on drop-square goes back into holdings
warp move (e.g. @@e4): whatever was on drop-square goes into holdings, leaving an empty square
suicide (e.g. @xe4): e4 is made empty, what was on it disappears.