TMCI

[H.G.Muller]

OK, I solved the key mystery. I have no private key set, I am using the Donation-ware version for this. But I had not realized that you then have to enter that as user name. Now it reacts to the key and happily replies "Smirf".

It now also reacts as expected to the time commands. So I am all set now. I will start with some 5'+1" games tonight, to see how it behaves, and then experiment some with giving times for a single move. I'll keep you informed.

[H.G.Muller]

I have it playing now, but Smirf seems to refuse promotion moves. In particular 'c2c1q' is refused (NULL code returned from DoCmd) in the following position (this was a Smirf self-play game):

[diag]6k1/5p2/4p1p1/4P2p/4PP1K/2R3PP/2p5/3r4 b - - 2 58[/diag]

Should the promotion piece be in upper case?

[Reinhard Scharnagl]

Congratulation for having come that far! Indeed, SMIRF waits for promoting piece letters in upper case. Its GUI returns simply one of the priorly requested move encodings, thus the GUI does not need to resynthisize the move strings. But I have looked into a debugged move call ... and found them written in upper case.

P.S.: the SMIRF GUI is intended to be very silly. Thus it is not able to create the moves itself, and it should not be by design. So the GUI simply has to select one from the moves the engine is proposing when iteratedly been asked for.

[H.G.Muller]

Indeed, capitals work.

OK, I have started two matches for tonight between Joker80 and Smirf (Donationware version, so far). One at 40 moves / 2 min, the other at 40 moves / 10 min. I'll report on the results tomorrow.

[Reinhard Scharnagl]

Well, then until then ... ;-)

[H.G.Muller]

Well, Smirf-Donation had a rough night, as I had not noticed that its default hash size is not more than 1MB. This made it a very unfair battle against Joker80 with 128MB...

I was first playing at 40/2' and 40/10', but early in the night I already noticed that Smirf was completely trashed at 40/2' (2.5 out of 26). But I blamed it on 40/2' not being a native time control: although it did distribute its time over the game evenly, very similar to what Joker80 did, it might not have enough flexibility in distributing the time over moves where it is needed, as i gets the time for each single move handed to it by the interface. So I decided to abort that match, and switch to the native sudden-death time control 5'+0.

At 5'+0 Smirf loses half the games on time, though. It uses about 3' for the first 20 moves, and due to the time-loss involved in polling cannot play extremely fast when time is running out. It scored 6.5 out of 43.

The other match, 40/10', has been running all night, and stood at 2.5 out of 17 for Smirf.

But, like I said, Smirf had to play practically without hash table, so these results are not really meaningful. I have now added setting the hash-table size, so I can play Smirf with 128MB as well. I have started new 40/2' and 5'+0 matches now, and the early indications are that Smirf does a lot better (I saw it win some games already). It still loses games on time in the 5'+0 match, though.

One nuisance is that I don't have a way to show the Smirf thinking (depth, score and PV). Is there a way to see when Smirf completes an iteration? Now I use this code for getting Smirf's move:

Code: Select all

                        p = (ProcAdd) ('C', '+', 0, NULL); /* start thinking */
                        if(p == NULL)
                        { printf("telluser Doesn't want to move\n"); continue;}
                        do {
                            Sleep(20);                          /* wait a bit */
                            p = (ProcAdd) ('C', 'B', 0, NULL); /* poll for ready */
                        } while(p != NULL);
                        p = (ProcAdd) ('C', 'I', 1, NULL); /* get PV      */
                        if(p == NULL)
                        { printf("telluser No PV\n"); continue;}
                        p = (ProcAdd) ('C', 'I', 2, NULL); /* get score   */
                        if(p == NULL)
                        { printf("telluser No Score\n"); continue;}
                        p = (ProcAdd) ('C', 'A', 0, NULL); /* get move    */
                        if(p == NULL)
                        { printf("telluser No move\n"); continue;}
                        Side ^= BLACK^WHITE;
                        printf("move %s\n", p);
                        p = (ProcAdd) ('E', 'M', 0, (char *) p); /* Make move */
                        if(p == NULL)
                        { printf("telluser Refuses own move\n"); continue;}



[Reinhard Scharnagl]

Hi, Harm,

during the polling you could call:

Code: Select all

p = (ProcAdd) ('C', 'I', 0, NULL); /* get move      */
p = (ProcAdd) ('C', 'I', 1, NULL); /* get PV      */
p = (ProcAdd) ('C', 'I', 2, NULL); /* get score and depth  */
 

and follow the thinking process.

You are right that SMIRF would need some cache and that it is not
prepared to play the timing model you had selected. Sudden death
timing model would fit much better.

SMIRF also is no specialist for Blitz time frames, though it supports it.

Whether the bonus-version would perform better should be object
of experiments. Be aware, that the DoCmd might have a shorter name.

Reinhard.

[H.G.Muller]

OK, I will start some 60'+0 games then on both cores, as the sudden-death at blitz time control still leads to frequent time loss for Smirf (it was at 2 out of 10, but 4 games were forfeits on time).

I will get to the bonus versions later. Would it be an idea to read the username and engine key from the SmirfGUI.ini file in the same directory as the SmirfEngine.dll is in? That way the user would never have to bother with keys.

btw, I uploaded what I have now to my website, and announced it on gothicchess.com.

[Reinhard Scharnagl]

Well, if there is a permanent problem with time frames, there possibly seems to be a slowdown by using the adapter. In that case it might help to communicate e.g. only 95% of the remaining amount of time for to avoid such time-out problems.

P.S.: I am not allowed to write / answer in the mentioned GC forum.

[H.G.Muller]

Yes, perhaps I should subtract 20msec times the expected number of moves (default 40 for the rest of the game), as I poll every 20 msec. Or perhaps even 40 msec, to be safe. It will require some experimenting.

Anyway, how should I interpret the PV and score strings? Does the score always start with a floating-point number in parentheses, whete the integer part is the search depth? Does the PV always start with the search time as mm:ss.s ? Would it be a viable strategy to poll for the score every 20 msec, and then interpret the number between the leading '(' and the '.', and then only poll for a PV and print both when this number changes?

[Reinhard Scharnagl]

It probably does not slow down the things to always ask for all three values. And the SMIRF GUI itself is polling much less times, so 50 msec might really be enough accompanied by an appropriate thinking time reduction of e.g. 100 msec, because that would not accumulate during a game. The evaluation sometimes also could be an (only estimated) mate value, in all other cases the look remains the same. In case of an occuring awaited mating it might look like "00:00.0 (05.00?) +M~??? 44...Qxe2+ ...". It seems to me, that you rarlely have watched the SMIRF GUI thinking. ;-) Here you could see, which forms might be displayed at all.

[H.G.Muller]

Indeed, I never play Human vs engine games. But it would be safer to ask anyway, as I cannot be 100% sure that the GUI displays the engine output unmodified (WinBoard doesn't...).

I had my test program print some polled PVs and scores while the engine was thinking, and it seems that in that case the score polling is really redundant, as the same info seems to be present in the PV string. There is no node count available?

What did you think of the idea to have the adapter read the SmirfGUI.ini file to obtain keys. Would that always work?

[Reinhard Scharnagl]

Sorry, no node counts are supported. The score is updated after every investigated move (in the deep and move number covering part), the PV is updated, when there is a new optimum value or move or (in brackets), if the optimal move pair has been changed - there is always a kind of bivariant calculation within a dynamic value window. If the Smirf gui has been working once, there always is an ini file, covering the generated or entered key sets. But the very moment after the first install of SMIRF there still is no ini file at hand, because it will be generated from the GUI. Nevertheless I see no problem to read the keys from the ini file, because that should be the legal situation of using Smirf and its GUI. If the adapter will look for DoCmd and _DoCmd entries, that approach would also cover the bonus versions of Smirf.

[H.G.Muller]

Great! Then I will set it up this way, and the adapter does not have to contain any secret keys.

[H.G.Muller]

OK, I posted a new version. It works with the bonus version now as well (recognizing both the DoCmd and _DoCmd entry point), and extracts the key from SmirfGUI.ini.

It does print a PV during search now, but somehow the PV is not displayed by WinBoard_F. I still have to figure out why that is. In the winboard.debug file I can clearly see it is send, but somehow WinBoard ignores it.

Btw, Joker80 vs Smirf-Donation at 60'+0 was standing at 6-6, when I got home. I will post the games on gothicchess.com. Now I have switched to the bonus version, also 1-hour games.

[Reinhard Scharnagl]

Well, Harm, you have come very far! There will be a lot of additional people who will try to find out, what is all about with 10x8 chess.

SMIRF still has no built in opening library. Thus, if the GUI is not providing distributed opening positions, the games will look very related. That also is one reason, why I decided to start developing 10x8 chess by playing CRC games, having thus a lot of different starting arrays.

In the PGN notation the specification seems to demand for an opening array setup, if the game is not based on the traditional 8x8 starting array. Providing such information would enable my SMIRF GUI to also load such games, which SMIRF itself is saving as PGN that way.

[H.G.Muller]

Good point, about the PGN. Although the PGN tags do mention the variant as " gothic", which should be sufficient identification for the opening array.

Anyway, my first concern is to make Smirfoglot also support pondering. What is the recommended protocol for that? After Smirf has made its own move, I should simply send 'C','P', and then wait for external input, to end it with 'C','-' if there is input I don't want to ignore?

[Reinhard Scharnagl]

SMIRF does permanent brain instead of traditional pondering on a presumed move. Simply send 'C', 'P' to start it, and finally stop it with 'C', '-' before initiating its normal thinking process.

On PGN: the variant tag has a comment character, because there is nothing standardized on variant names in PGN - maybe in Winboard, but engine protocol specifications are independent from the PGN format.

To use a provided starting array is much better for to define the base of a chess variant, as long as it uses common FEN. Thus it is important to COMPATIBLY extend the FEN for to support variants also in PGN.

You could easily find out, that traditional chess, fischerandom or nocastle are to be setup doubtlessly simply by specifying the matching starting array using (if you ask me) X-FEN, for to have NOT different FEN strings e.g. for the Chess960 position number 518, which is identical to standard chess starting array. Whether you would specify here a variant tag or not would change nothing, because the position and the rules are the same. Thus a variant tag in PGN is nothing but a helpfull comment.

[H.G.Muller]

OK, I will put in the permanent-brain feature. Can I assume that the Smirf engine remains fully responsive to other commands while it is pondering? i.e. can I feed it the black and white times before stopping the pondering with "C-", or do I have to stop it first?

As to the PGN, this really is a WinBoard matter, over which the Smirfoglot adapter has no control whatsoever. That I also happen to be the WinBoard_F programmer is purely accidental, and I don't want to confuse matters by mixing those roles. The purpose of this action was to make it possible for Smirf to communicate with WB engines. Not to improve or change the communication between WinBoard and WinBoard users. People choose whatever GUI they like, based on how it displays the board and in which format it saves positions and games. If they don't like the PGN format that WinBoard produce, they can use other GUIs that do a job more tailored to their preferences. There are plenty of GUIs that support WB engines.

My attitude towards standards is a bit different from yours. If something is not standard, but it works, I just elevate it to standard. Furthermore, I consider diversity of representation a good thing. Naming the variant seems a good, compact and unambiguous way to identify the initial setup. I like that much more than having a very long FEN string, which I would have to scrutinize really carefully to figure out that it was the Gothic array. As long as WinBoard is able to read back the PGN and FEN styles that it writes, and does a reasonable job in understanding most formats used by others, I am completely satisfied. People that use GUIs that do not provide such input flexibility can always edit the FEN string into their PGN before feeding it to the GUI.

Btw: after one night of play, Smirf-bonus was leading to Joker80 6.5-5.5. I'll let it run for the rest of the day.

[Reinhard Scharnagl]

OK, I will put in the permanent-brain feature. Can I assume that the Smirf engine remains fully responsive to other commands while it is pondering? i.e. can I feed it the black and white times before stopping the pondering with "C-", or do I have to stop it first?

It should remain always responsive. Though I have not tested each sequence, SMIRF should behave good - I hope so. ;-)

As to the PGN, this really is a WinBoard matter, over which the Smirfoglot adapter has no control whatsoever. That I also happen to be the WinBoard_F programmer is purely accidental, and I don't want to confuse matters by mixing those roles. The purpose of this action was to make it possible for Smirf to communicate with WB engines. Not to improve or change the communication between WinBoard and WinBoard users. People choose whatever GUI they like, based on how it displays the board and in which format it saves positions and games. If they don't like the PGN format that WinBoard produce, they can use other GUIs that do a job more tailored to their preferences. There are plenty of GUIs that support WB engines.

My attitude towards standards is a bit different from yours. If something is not standard, but it works, I just elevate it to standard. Furthermore, I consider diversity of representation a good thing. Naming the variant seems a good, compact and unambiguous way to identify the initial setup. I like that much more than having a very long FEN string, which I would have to scrutinize really carefully to figure out that it was the Gothic array. As long as WinBoard is able to read back the PGN and FEN styles that it writes, and does a reasonable job in understanding most formats used by others, I am completely satisfied. People that use GUIs that do not provide such input flexibility can always edit the FEN string into their PGN before feeding it to the GUI.

Well, do it your way. Nevertheless those have been my thoughts. It is a great task anyway to support also 10x8 chess and even TMCI in Winboard.

Btw: after one night of play, Smirf-bonus was leading to Joker80 6.5-5.5. I'll let it run for the rest of the day.

Well, still I see a problem in SMIRF not randomizing its first moves a little bit.