TMCI

[H.G.Muller]

This indeed offers a danger for the games not really being independent. I have not had time to look at the games at all, so I couldn't say if there are dupilcats, or many games that follow the same path until after the game is already decided. In normal Chess I guard against this by playing from the Nunn positions, but there is not yet any 10x8 equivalent of that.

Now I must say that against Joker80 the danger is not as large as against many other engines, as Joker randomizes all its moves to a certain extent. The main bias would thus be a preference for the first few opening moves, leading to a position that is strategically unbalanced in favor of one of the engines. So I agree that the current results cannot really be interpreted as a scientific measurement of the strength difference of Joker and Smirf. To be credible such a measurement would have to be done by an independent person anyway, so that is not the purpose now.

One way to avoid the problem (which I use in my piece-value measurement project) is to start from shuffled opening arrays. (So play caparandom, really, but as Joker80 is not a shuffle-Chess engine I have to limit the opening arrays to those that have King and Rooks in the usual place. And on 10x8 this even gives 216 possible shuffles if you restict the Bishops to be on opposite colors, and have one B and one N on either side of the King. And they can be played with both colors, so that gives 432 games that are guaranteed to be different.

Another procedure could be to always start from the same opening position, but play games with reversed colors after a variable, small number of moves. E.g. play a game from scratch, and then take the position after 6 moves (which presumably is still pretty even), and use that as a starting point for the next game with the colors reversed. That way you would eliminate any bias that could have developed in the first 6 moves, and these six moves would only serve to create some variety in the starting positions.

[F.Huber]

OK, I will put in the permanent-brain feature.

Nice to hear that!
But IMO it would also be very (if not even more) important to implement the '?' command - now you can´t stop Smirf´s thinking and so no 'analyzing mode' is currently possible.

[H.G.Muller]

OK, pondering implemented; based on the task manager it seems to work. I will try a ponder-on match between Joker80 and Smirf tonight. This time at 15'+0.

The '?' command is out of luck. This is non-trivial, as I would have to look at the input without blocking, and I forgot how to do that. Smirfoglot was only meant for enabling engine-engine games. For analyze mode, can't you simply do that in Smirf's native GUI? You only do that with one engine, not?

[F.Huber]

The '?' command is out of luck. This is non-trivial, as I would have to look at the input without blocking, and I forgot how to do that.

Do you really mean that your adaptor can´t read any commands from the Winboard-GUI while the Smirf-engine is thinking?

Smirfoglot was only meant for enabling engine-engine games. For analyze mode, can't you simply do that in Smirf's native GUI? You only do that with one engine, not?

Of course interrupting the engine is possible in the SmirfGUI at any time, but I thought your Smirfoglot should be a usual adaptor, which would also allow a normal game against Smirf in Winboard.
If it´s indeed only for engine matches, then it´s uninteresting for me, sorry.

[H.G.Muller]

For a normal game, you also don't need '?'... Why would you want to play a normal game against Smirf under WinBoard while you can also play a normal game against it in its own GUI? There seems no need for this.

And indeed, Smirfoglot uses getchar() for reading input, and if you do that while there is no input, you hang. And then Smirf's move would never be printed, once Smirf finishes thinking, as Smirfoglot is busy waiting for input.

[F.Huber]

For a normal game, you also don't need '?'... Why would you want to play a normal game against Smirf under WinBoard while you can also play a normal game against it in its own GUI? There seems no need for this.

Ok, no problem, I just hoped I could use the Smirf engine in my prefered Arena-GUI as any other WB/UCI engine. But if your intention was only to let it play in engine matches I´ll have to accept this.

And indeed, Smirfoglot uses getchar() for reading input, and if you do that while there is no input, you hang. And then Smirf's move would never be printed, once Smirf finishes thinking, as Smirfoglot is busy waiting for input.

I´ve only some basic knowledge of ´C´ but I can´t believe that there´s no command for a nonblocking-read from stdin!?
However there would always be the method of using a separate thread for this reading ...

[H.G.Muller]

Well, there is, but it is complicated and platform dependent, and I would have to figure out where it is. I don't know off hand how to do it. And I don't have the time now to figure it out.

I think many WinBoard engines do not support the '?' command. The WB protocol definition explicitly mentions that you dont have to support it. None of my own engines supports it. So as far as I am concerned, you can run Smirf through Smirfoglot under Arena "just like any other WB engine". But you should be prepared that "any engine" might not support "move now". (Btw, Smirfoglot also does not support "undo".)