how many chess engines are they

[Reinhard Scharnagl]

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

There the TMCI protocol has been published, which is the way SMIRF communicates with its GUI. Inside of that open draft you could find out, that different kind of time controls are supported. But this also could be learned from working with Smirf's own GUI for a small amount of time. Ignoring a thing mostly would not help to understand a thing. There had been times, where such would have touched me more than today.

... It is also a bit strange that someone first creates his own protocol ...

I commented on that already in this thread: neither Winboard nor UCI did support 10x8 Chess or Chess960 the time TMCI has been proposed. This has been done, because there has been no chance to extend those protocols compatibly in cooperation, despite of my attempts to find necessary agreements with their presumed authors or preservers. Current X-FEN e.g. has been redesigned as a compatible compromise but has been refuted with ostentation by introducing Shredder FEN, whereas my Chess960 numbering scheme (as introduced in my book) has been occupied. Thus TMCI is the result of common obstinacy against the need of a compatibly extended protocol.

I had presumed, SMIRF / Smirfoglot were missing by oversight. Now I had to learn, that this is by intention. Thank you for the clarification. It will help me a lot to take my decision against an implementing of any Winboard related protocol within SMIRF's successor engine.

[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

There the TMCI protocol has been published, which is the way SMIRF communicates with its GUI. Inside of that open draft you could find out, that different kind of time controls are supported. But this also could be learned from working with Smirf's own GUI for a small amount of time. Ignoring a thing mostly would not help to understand a thing. There had been times, where such would have touched me more than today.

Of course I looked a bit into the GUI, but it is still my freedom how much time I spend on what and not your business.
The GUI and HG told me that you don't support the standard moves/time timecontrol, so I have no idea what you are talking about?
It is only the adapter from HG which makes Smirfs timecontrol scheme compatible with the standard timecontrol.

Code: Select all

<quote HG>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.</quote>

... It is also a bit strange that someone first creates his own protocol ...

I commented on that already in this thread: neither Winboard nor UCI did support 10x8 Chess or Chess960 the time TMCI has been proposed. This has been done, because there has been no chance to extend those protocols compatibly in cooperation, despite of my attempts to find necessary agreements with their presumed authors or preservers. Current X-FEN e.g. has been redesigned as a compatible compromise but has been refuted with ostentation by introducing Shredder FEN, whereas my Chess960 numbering scheme (as introduced in my book) has been occupied. Thus TMCI is the result of common obstinacy against the need of a compatibly extended protocol.

I had presumed, SMIRF / Smirfoglot were missing by oversight. Now I had to learn, that this is by intention. Thank you for the clarification. It will help me a lot to take my decision against an implementing of any Winboard related protocol within SMIRF's successor engine.

I really don't care for Chess960 and this probably won't change in the future, because I am chess tournament player since 25 years.
Thus all this about FENs etc. is irrelevant for me. I like the GUI and it was great to develop a new own protocol, but why can't you
still see that Smirf now is TMCI and not WB/UCI? None of the programs listed needs an adapter to run in a native WB/UCI GUI,
that's all, this is just per definitionem and has nothing to do with you or Smirf or anyone. If you would distribute the adapter
as yours in your own Smirf package it could be considered different.
Also I would find it quite silly to make any decisions on future programs, just because of this absurd thread. Actually I would
find it less silly if I would stop wasting time in a community which tries via dictatorship attitudes to force a T for a W/U.

[Reinhard Scharnagl]

... stop wasting time ...

My activities e.g. in this forum has also been an offer to participate in an attempt to compatibly extend computer programs' ability to play more than the traditional game of chess merely as initial, which has become somehow boring with its Gigabyte opening and endgame tables during the last years.

Of course such an offer could be refuted. Thus it will be best for me to have a break here.

[Matthias Gemuh]

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.

This is how I understand it:

Smirfoglot is a WB engine, written by H.G.Muller.
This engine uses a DLL written by someone else (Reinhard).
Correct ?

Matthias.

[Matthias Gemuh]

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

Reinhard simply doesn't tolerate it if his proposals are not accepted unmodified.
I did not need a new protocol to write the WB/UCI engine ArcBishop which supports normal chess, Chess960 and 10x8 variants.

Matthias.

[Reinhard Scharnagl]

Reinhard simply doesn't tolerate it if his proposals are not accepted unmodified.

This is not at all true. Look e. g. at X-FEN. This has been changed in its encoding formula for castling rights from FRC-FEN to X-FEN to establish a possible compromise when having a discussion on how to encode Chess960 positions which had been introduced to me. And as for 10x8 chess there has been a decision to encode ten empty squares in a row as "10" instead of another attempt to match some existing variant encoding approaches. But I rejected proposals like e.g. the still unmodified Shredder FEN, because it establishes different encodings for identical positions in a lot of cases where remaining pieces with castling rights were positioned at traditional places only. And this is not because of any kind of missing tolerance from my side, but by intolerance e. g. towards already existing growing Chess960 game and opening array databases at that time.

Moreover this stuff is completely outside of the Smirfoglot discussion, because none of those things has been affected here.

[Matthias Gemuh]

Reinhard simply doesn't tolerate it if his proposals are not accepted unmodified.

This is not at all true. Look e. g. at X-FEN. This has been changed in its encoding formula for castling rights from FRC-FEN to X-FEN to establish a possible compromise when having a discussion on how to encode Chess960 positions which had been introduced to me. And as for 10x8 chess there has been a decision to encode ten empty squares in a row as "10" instead of another attempt to match some existing variant encoding approaches. But I rejected proposals like e.g. the still unmodified Shredder FEN, because it establishes different encodings for identical positions in a lot of cases where remaining pieces with castling rights were positioned at traditional places only. And this is not because of any kind of missing tolerance from my side, but by intolerance e. g. towards already existing growing Chess960 game and opening array databases at that time.

Moreover this stuff is completely outside of the Smirfoglot discussion, because none of those things has been affected here.

There is one thing I should congratulate you for, Reinhard.
You always remain cool in verbal battles

Matthias.

[Olivier Deville]

Hi all

I can witness Smirf + Smirfoglot behaves perfectly here as a winboard engine.

Olivier

[Matthias Gemuh]

Hi all

I can witness Smirf + Smirfoglot behaves perfectly here as a winboard engine.

Olivier

I too have never noticed anything abnormal (with free DLL).

Matthias.

[H.G.Muller]

[quote="Matthias Gemuh]Smirfoglot is a WB engine, written by H.G.Muller.
This engine uses a DLL written by someone else (Reinhard).
[/quote]
This is one way of formulating it, albeit one that suggests more credit for me than I deserve.

Perhaps fairer would be to consider Smirfoglot plus the DLL that contains its most essential code as a WinBoard engine jointly written by Reinhard and me. Just like the WinBoard version of Dabbaba is a WinBoard engine jointly written by Jens B. Nielsen and Jim Ablett.

IMO it should not make any difference if I copy-pasted the source code of another engine into my own source code, or if I copy-pasted the binary code into my executable. There is no requirement on WinBoard engines that they should exist in source code. Poking hex machine code directly in memory is just as valid a way to create an engine. Perhaps that is exacty what i am going to do one day, to have a go at the record for smallest executable.

[Reinhard Scharnagl]

... so when could we expect a change within that list?

[H.G.Muller]

I think Guenther made t very clear that he'd rather have an incomplete list than add Smirfoglot to it... And, as he ponted out, it is his list.

If you want me to fix the mutiple PV per iteration problem, it would help if you could tell me what is the easiest to look for to see f SMIRF has put out a new PV. While SMIRF is searching, Smirfoglot is polling it 50 times per second for PVs, and I don't want to put out all those PVs to winBoard. Currently I only check for the depth to have changed, but that obviously does not work if there are multiple PVs emitted with te same depth. It only would print the first.

[Reinhard Scharnagl]

I think Guenther made t very clear that he'd rather have an incomplete list than add Smirfoglot to it... And, as he ponted out, it is his list.

Of course, but presenting some strange arguments against a mentioning established the idea, that he might be open at last for some more convincing.

If you want me to fix the mutiple PV per iteration problem, it would help if you could tell me what is the easiest to look for to see f SMIRF has put out a new PV. While SMIRF is searching, Smirfoglot is polling it 50 times per second for PVs, and I don't want to put out all those PVs to winBoard. Currently I only check for the depth to have changed, but that obviously does not work if there are multiple PVs emitted with te same depth. It only would print the first.

It would be sufficient to check the PV data elements once a second (and at the de facto answering moment, which is actually skipped) if being changed compared to those from the previous check, and print them out when being different.

Thank you for any fixing!