Shartranj!

[hgm]

I have one question. I noticed fairy moved instantly at times. Is it pondering? could there be any issue were fairy is using cpu that pulsar is trying to use as pulsar does not ponder? What are the ethics here? My tendency is to believe pondering should only be allowed if both engines ponder or if the match gives a dedicated machine to each engine.

No, Fairy-Max cannot ponder at all, even if I would tell WinBoard to switch pondering on. What you see is an artifact of the Javascript viewer: it probes only every 10 sec for new moves. (To reduce bandwidth on my slow uplink.) And when there are multiple moves added since the last probe, it displays them at a rate of one per second. So if any thinking period shorter than 10 sec might produce the moe in the same probe interval, and will be displayed 1 sec after the previous move.

At 40/5' the average time per move is 300/40 = 7.5 sec. So it should happen quite often that two moves come in the same 10 sec interval. Especially since the time management of Fairy-Max is such that it always finishes an iteration. With an effective branching ratio of ~4, that makes the time it spends on a single move vary somewhere between 3-15 sec.
You should see the same thing happening to Pulsar, now and then. (Perhaps less often, if it distributes time more evenly over the moves.) I am running the tourney anyway on a dual core, and the other core is currently idle. (When I have a program that plays Shatranj satisfactorily I am going to run 40/1' games there to determine the piece values.) You can find the times that were actually spend on each move in the PGN: after each move it gannotates {depth/score time}. The time is given in seconds, or as min:sec.

[adams161]

In watching a game between pulsar 33 and pulsar 34, i felt pulsar34 was winning. i got up and did stuff and i swear i saw the same game, with pulsar 34 taking pulsar 33 's last piece, and pulsar 34 being a knight up, ( well i cannot be certain of who won pulsar 33 or pulsar 34) but xboard adjudicated it insuficient mating material. This is a win for one of the engines, pulsar 34 i think. Can this be clarified? have any other games been misadudicated?

Mike

[hgm]

They occasionally play the same games, I noticed that too.

I guess you are right. In Shatranj I should play with insufficient-mating-material adjudications switched off. Because the bare-King adjudication only works after 1 move, to give the opponent the probability for a recapture that would bare both Kings, the adjudication of KNK gets the opportunity to kick in before the baring rule.

I don't know how many such adjudications there were. Just scan the PGN file for the word 'insufficient'. So far the engines are too buggy to attch many conclusions to the results anyway. The main purpose so far is debug the engines and testing method. I put "/materialDraws=false" now in the winboard.ini.

[edit] I see that adjudication between Pulsar 33 and 34 only once in the PGN. Perhaps you did hit 'refresh' too soon after the game finished. There is a 15-sec pause between games, to give all viewers the opportunity to fetch the last moves of the game, before overwriting the file with moves. If you refresh during that period, you will re-fetch the game that just finishes, and the viewer will display it again.

I saw only one other insuff. material adjudication, between Fairy-Max and Pulsar 34, and that was two bare Kings, so it was OK although unintended.

[adams161]

yes repeated games are the issue, that was the point of the book, i encourage you to make a book even if shallow to help vary the moves. I would love to actually put shatranj knowledge in teh book, but from experience with programming wilds i realize even a shallow book that varies say move 1 2 and 3, is going to help keep someone from repeating a line he won in the last or second to last game ( at same color).

I wasnt expecting a full review of every game played. there have been like 200. primarily i was concerned with the last 2 matches. the one between pulsar 34 and fairy max ( that match is most critical that i have the score ) and the one between pulsar33 and pulsar34. right now i'm on a laptop and i dont have winboard_f installed. i will review the pgns. If you could also clarify in particular if there were any mis adjudications in the pulsar 34 and fairy max match i would appreciate it. the pulsar 33 pulsar 34 match seems to be showing that pulsar34 is dominant and i think a more exact score would only illustrate that more so.

Mike

[hgm]

In Fairy-Max I randomize the first 3 moves of either side, by adding a random value of 20cP to the scores in the root. That has about the same effect as your book, but has the advantage that it is not specific to a certain variant, but automatically works for all. The random value is chosen such that it is not possible to overcome the penalty for middle-game King moves, so that it won't start with things like 1. e4, ... 2. Ke2. But otherwise, every move that does not blunder away material has a chance to be played. So usually duplicate games are no problem in Fairy-Max.

[hgm]

I finally succeeded in getting my tablebase generator running for Shatranj, and am running some end-games now. The important difference with Chess is of course the baring rule. That means 3-men end-games are automatically won, as one of the Kings must be bare, and the most simple end-games are 4-men.

While doing this, it started to dawn on me that there is an effect that makes weak pieces much more important in Shatranj than in Chess. In Chess a Pawn can be a decisive advantage, but only because it can promote to Queen, forcing the opponent to give a piece for it. But in Shatranj a Pawn (or Ferz, or Elephant) can convey a winning advantage through just being there, due to the baring rule. A 2+2 men ending that is a draw, can become a win by the presence of a fifth piece, no matter how weak. Because suddenly it makes trading the other pieces a win for the side who has it, rather than an insufficientt-material (KK) draw. For instance, KRKN is generally draw (like in normal Chess; the baring rule makes no difference as KRK in normal Chess is also 100% won once the Rook side gets to move). But add an Elephant (KREKN), and it seems to be generally won in Shatranj. With Chess rules, KREKN would in general be draw, as black can defend without having to avoid the rook trade.

[adams161]

i'd hate to have to play against tablebase in shatranj

One issue with fers ( queens ) and elephants ( bishops ) and pawns, is the equivalent in chess of the bishop of opposite color issue, can lock a board down with no progress possible even if your 2 pieces ahead. I'll have to watch more games, and program for pulsar some endgame tables. but in teh games i watched there seemed to be eathier winning chances or drawing chances depending on if the bishop or queen was on a light square or dark square.

Mike

[hgm]

My impression from watching the games is that this color-boundedness is a key factor in being a strong Shatranj player. And the Pawns should be counted as color bound from their romotion square, as they promote to Ferz. So it seems important to save one or two Pawns of opposite color from your Ferz.

I made a special Shatranj version of Faity-Max now ('ShaMax'), which nows the baring rule. Initially I gave the side to move the same score as for a King capture, when its opponent has a bre King, and it has more material itself. (Meaning that the move leading to it in the node below gets the score of an illegal move. This means that the moves that bares the King is considered a checkmate (well, a stalemate really, but in Shatranj that is the same). But this led to problems with WinBoard claim testing, as WinBoard adjudicates the baring only one move later. Idealy WinBoard should think ahead to see if recapture is possible. (Like on a check it thinks one ply ahead to see if evasion is possible), but this is a lot of work for a game that is rarely played. So I guess I will take the lazy approach and solve it in the protocol definition, allowing engines to claim only when at the start of their move the opponent is bare.

So I have changed the score that ShaMax awards itself when the opponent is bare to mate-in-1, in stead of King capture. Then it doe not trigger the checkmate message (which is triggered by score). In stead I added explicit code to test for a bare King in the PrintResult message.

[hgm]

It seems the baring rule is quite important. The version of Fairy-Max knowing about it (ShaMax) beat the version unaware of it by 60%. OK, this was only in 32 games. But 22 of those were draws. In the 10 decided games there were 8 bare-King victories by Shamax, and only 1 by Fairy-Max. That is a sizable difference.

I have also started the piece-value measurements, using ShaMax. I started with measuring the Pawn-odds score (c-Pawn). After 156 games, the one with the extra Pawn is leading by 56%. This is a lot less than in normal Chess. But mainly because the draw percentage is so much larger. Of course the Pawn-odds score is just for reference; in itself it doesn't say anything about piece values. Next test will be Ferz-odds, Ferz vs Pawn, Knight vs Ferz, Knight vs a pair of Ferzes. Then I will try Elephant odds, Elephant vs Pawn, Elephant vs Ferz, Elephant+Pawn vs Ferz. After all that, I should have a reasonable impression of the value of the light pieces compared to the Knight.

[hgm]

Ferz odds was worth a 67.5% score in 100 games. I am not doing a very high number of games now, these are just exploratory measurements to get a vague idea of the piece values, so I can configure at least approximately correct values in the engines when I start doing the more accurate tests.

So the advantage of a Ferz in the opening produced an excess score (i.e. over 50%) was 17.5%, while the advantage of a c-Pawn only gave an excess score of 6%. That does suggest the Ferz is worth 3 times more than the Pawn. This makes the Pawn quite less valuable than its recommended value from 1100 years ago, and about as much as what I give it now (P=50, F=150). But the error bars are still large.

I now started Ferz vs Pawn and double Elephant odds.