how many chess engines are they

[mainsworthy2]

http://www.rwbc-chess.de/wb_chron.htm

the above link shows 470

but how many chess engines are they? this has puzzled me for a while!

mark

[Reinhard Scharnagl]

Well, it is not that important, but e.g. SMIRF/Smirf-o-glot still is missing.

[mainsworthy2]

I bet many old Engines could be fun to play

[Guenther Simon]

Well, it is not that important, but e.g. SMIRF/Smirf-o-glot still is missing.

The chronology lists only contain(and names this in the header) WB/UCI protocol programs and Smirf is none of both.

Guenther

[H.G.Muller]

But arguably Smirfoglot is a WB engine. It does not even start up another process (like Polyglot) or another thread (like many engines) for computing the moves. It only uses a subroutine in a DLL. Like many other engines, e.g. all those probing Scorpio bitbases. There are also many engines that are dependent on the cygwin1.dll for there running.

I think it should be the engine authors decision whch routines in his program he wants to put in a DLL and which in the .exe.

[Guenther Simon]

But arguably Smirfoglot is a WB engine. It does not even start up another process (like Polyglot) or another thread (like many engines) for computing the moves. It only uses a subroutine in a DLL. Like many other engines, e.g. all those probing Scorpio bitbases. There are also many engines that are dependent on the cygwin1.dll for there running.

I think it should be the engine authors decision whch routines in his program he wants to put in a DLL and which in the .exe.

Well, but Smirfoglot doesn't play chess right? I don't see anything we can argue about here. My list only allows either
WB or UCI engines, nothing more. There is also no Fritz or whatever in my list.
(BTW independent from the above, AFAIK there are/were still a lot of issues with Smirf and Smirfoglot, at least from what
I remember having seen in some threads?)

Guenther

[H.G.Muller]

The combination Smirfogot.exe + SmirfEngine.dll is a working WB engine that plays Chess. Just like BBChess.exe + cygwin1.dll is a Chess engine . And Scorpio + egbbdll.dll are generally considered an engine, despite the fact that move-selecting code is located in a DLL.

I am not aware of any issues with Smirfoglot. SMIRF has a lot of issues, e.g. with piece evaluation and time management, but that is Reinhard's problem.

[Guenther Simon]

The combination Smirfogot.exe + SmirfEngine.dll is a working WB engine that plays Chess. Just like BBChess.exe + cygwin1.dll is a Chess engine . And Scorpio + egbbdll.dll are generally considered an engine, despite the fact that move-selecting code is located in a DLL.

I am not aware of any issues with Smirfoglot. SMIRF has a lot of issues, e.g. with piece evaluation and time management, but that is Reinhard's problem.

I don't agree and I must say I don't care. Also the above examples are quite weird, too weird for leaving more words, except, that dlls
are not the key. I just want to add that I am sure that I will test it too, but that is of course independent of an entry in my chronology.
It just will happen, because it will or will not work...

For the issues: Except it seems that only a handful of people so far tried it, all reports, even your own say that it loses often on time
with your adapter, but may be this is fixed meanwhile? BTW the hashsize is fixed to a max of 64MB(by the SmirfGUI) and the example
on your smirfoglot site seems missleading as it shows an example with 128MB.

Guenther

[Reinhard Scharnagl]

SMIRF originally has not been written as a Winboard or UCI engine, simply because there has not been any 8x8 and 10x8 enabled GUI for that. Thus I had to write one myself using a self defined protocol TMCI. But when HGM did his welcomed attempt to open Winboard for a wider range of variants, I cooperated with him in that case, as he developed his Smirf-o-glot adapter.

Why this combination still will be ignored in that list, is hardly to be understood. Of course SMIRF is an engine merely at amateur level. A lot of work has been put into its own GUI, which mostly has been ignored like its engine, too. Thus today there is no more big attempt, to improve its strength for public. SMIRF is no open source program and best compiles are for supporters only *). Therefore it might be unterstandable, when SMIRF/Smirfoglot ist not mentioned in your high level only list.

PS.: *) There always is an optimized RAM unrestricted version of SMIRF only for supporters having got their personal key set. SMIRF's GUI could be used (but not distributed) by anyone privately, and it includes a mostly less actual SMIRF engine of about 1/2 speed having a 64 MB cache RAM limit. But this would be sufficient to experience the taste of SMIRF.

[H.G.Muller]

I don't agree and I must say I don't care. Also the above examples are quite weird, too weird for leaving more words, except, that dlls
are not the key.

I agree that the examples are quite weird, which is exactly why they were such good examples: they are just as weird as consdering SMIRF + Smirfogot not to be a WinBoard engine.

If DLLs are not an issue, it boils down to this: I made a WinBoard version of SMIRF by replacing its dedicated GUI by a WB interface, keeping only the engine part. Just as Jim Abblet has converted many stand-alone Chess egines (e.g. Dababba) to WinBoard engines by replacing their dedicated GUI code with a WB driver.

As to the time losses; Smirfoglot faithfully transmits the time it receives from WinBoard to the SMIRF engine. It even deducts a fraction of a second to compensate for the worst-case delay that might be introduced by Smirfoglot polling the search for completion and best move. Smirf distributes its time very agressively to the beginning of the game, and does not seem to be able to move arbitrarily fast, becuase it seems to always search to a certain minimum depth before it coniders stopping or even produces a move. This is a good recipe for losing on time in blitz games. Of course I can force another distribution of the time over the game from Smirfoglot, by lying to the SMIRF search about the time it should use. So that it uses a more reasonable distribution of its time over the game, and does not put itself in a position where it has to move faster than it actually can. But I don't feel this is my task. Reinhard should be the one to decide how SMIRF distributes its time.

[Reinhard Scharnagl]

... Reinhard should be the one to decide how SMIRF distributes its time. ...

Well, I repeatedly noted that SMIRF has not been designed for to play Blitz, nevertheless it should be able to do so. Blitz timing seems to be loved by engine testers having only a small amount of time or patience. But I myself did not much of such testing because of not being mainly interested in 8x8 speed games because of the internal nature of my engine. Nevertheless SMIRF currently participated in http://www.open-aurec.com/chesswar/Chesswar014/Chesswar014FSt.htm without any timing problem reported to me.

[H.G.Muller]

Chess War is 40 moves / 20 min, which is OK for SMIRF. It is just the sub-5-min games where it gets into trouble.

[Reinhard Scharnagl]

Harms, sorry for that. When I saw Winboard_F reporting at SMIRF / Smirfoglot only the first PV line per ply level but missing those occasionally reported by SMIRF later, I have been convinced to make something wrong when testing SMIRF using Winboard_F. Maybe there is a problem when SMIRF is answering by a move reported second to a ply level or later leading Windoard_F / Smirfoglot errornously to wait a small amount of time for the next ply answer line? I don't know. Under the SMIRF-GUI itself there is no timing problem using the SMIRF engine even at Blitz timing. So the best seems to be not to use SMIRF at Blitz timings at this moment.

[H.G.Muller]

I am not sure what you mean. This is the code for letting smirf move:

Code: Select all

                        p = (ProcAdd) ('C', '+', 0, NULL); /* start thinking */
                        if(p == NULL)
                        { printf("telluser Doesn't want to move\n"); continue;}
                        do {
                            if(Post && (cnt & 15) == 1)
                            {   int d, min, x; float sec, score;
                                p = (ProcAdd) ('C', 'I', 2, NULL); /* poll PV */
                                if(p != NULL &&
                                   sscanf(p, "%d:%f (%d.%d%c) %f", &min, &sec, &d, &x, &x, &score)==6 &&
                                   d != lastDepth)
                                {   lastDepth = d;
                                    printf("%3d  %5d %5d  100000 %s\n",
                                         d, (int)(score*100), (int)(6000*min+100*sec), p+24);
                                    fflush(stdout);
                                }
                            }
                            Sleep(20); cnt++;                  /* wait a bit */
                            p = (ProcAdd) ('C', 'B', 0, NULL); /* poll if ready */
                        } while(p != NULL);
                        p = (ProcAdd) ('C', 'I', 1, NULL); /* poll PV */
                        if(p == NULL)
                        { printf("telluser No PV\n"); continue;}
                        p = (ProcAdd) ('C', 'I', 2, NULL); /* poll score */
                        if(p == NULL)
                        { printf("telluser No Score\n"); continue;}
                        p = (ProcAdd) ('C', 'A', 0, NULL); /* fetch move */
                        if(p == NULL)
                        { printf("telluser No move\n"); continue;}
                        Side ^= BLACK^WHITE;
                        printf("move %s\n", p);


It polls the search every 20 msec with a CB0 command, to see if it is done. If it is not done it immediately uses a CI2 to request a PV (if 'show thinking' is on), and if one with different depth from the prevous one it is printed.

If the CB0 poll revealed that the search was finished, it tests if there is a PV and score with CB1 and CB2 (complaining if there isn't one, but not really using it if there is), and then fetch the move with CA0 to print it. I don't see how that could give a delay of more then 20 msec...

[Reinhard Scharnagl]

Harms, Today I downloaded your winboard package 4.3.14k and tried a game with the current Smirf engine.

There neither the blitz timing problem nor the one line per ply only report problem seems to be left.

Thus I wait for people to report NEW problems if any.

Regards, Reinhard.

PS.: Sorry, the one line per ply only report problem seems still to be there.

[H.G.Muller]

Is this a problem? From the code above, you can see that it is intended behavior. I only print out the PV if the depth is different from the previous depth. It would be easy enough to print it for any difference, if you prefer that.

[Reinhard Scharnagl]

Is this a problem? From the code above, you can see that it is intended behavior. I only print out the PV if the depth is different from the previous depth. It would be easy enough to print it for any difference, if you prefer that.

Currently this is no functional problem, merely there is a lack of information while watching Smirf engines playing.

[Guenther Simon]

I don't agree and I must say I don't care. Also the above examples are quite weird, too weird for leaving more words, except, that dlls
are not the key.

I agree that the examples are quite weird, which is exactly why they were such good examples: they are just as weird as consdering SMIRF + Smirfogot not to be a WinBoard engine.

If DLLs are not an issue, it boils down to this: I made a WinBoard version of SMIRF by replacing its dedicated GUI by a WB interface, keeping only the engine part. Just as Jim Abblet has converted many stand-alone Chess egines (e.g. Dababba) to WinBoard engines by replacing their dedicated GUI code with a WB driver.

Ok as you still insist, a few last words about what the key is at least for _me_ (and I never thought this had to be discussed at all,
because IMO it is quite clear what an UCI/WB engine is and moreover it is _my_ list ). Jim adapts some WB interface code
_into_ an _existing open source_ and this creates WB versions of a very few programs, which would be _dead_ otherwise,
because they are _not developed anymore_.
_You_ made an _adapter_ for a non WB program which is _not open_ and is _still under development_and could be _released as WB program
by itself from the author_, but it did not happen. If you are unhappy about my decision you could perhaps create your own list.
It is also a bit strange that someone first creates his own protocol and later is unhappy not to be listed under a context he didn't like before.

Guenther

[Guenther Simon]

Chess War is 40 moves / 20 min, which is OK for SMIRF. It is just the sub-5-min games where it gets into trouble.

I thought I read somewhere that it also doesn't support moves/time timecontrols, am I wrong?

Guenther

[H.G.Muller]

Well, like you say, it is your list. You can put arbitrarily incorrect information in there, if you want. That does not bother me. But that doesn't change the fact that Smirfoglot is a WinBoard engine which happens to locate some of its code in a DLL so that it can be shared. It is not your list that determines which is a WinBoard engine, and which not. Being a WinBoard engine is an objective fact.

Of course I am not going to start my own list. I have no interest in such lists. I haven't even looked at yours yet...

Smirfoglot does support all WinBoard time controls. The SMIRF search code does not support moves per time, only time for a single move and time for an entire game. But Smirfoglot does contain time-management code to calculate the time for each single move from the remaining time on the clock and the number of moves to go to the next TC, and then runs the search in tme-per-single-move mode.