New engine: KnockOut 0.7

[Sven]

I estimate the engine would be much stronger would it not lose so many games on time. I have Winboard log + PGN games if you would like to see.

Thanks for reporting! Please send your logs + PGN to the email address that you find at the bottom of "readme.txt".

Sven

[Sven]

KnockOut 0.7-build012 has the following known problems:

- some time losses, especially in X+0 games and with incremental time control;

- the clock adjustment triggered by the "time" WinBoard command has a severe problem that affects all time controls - fixing it will not only reduce time losses but also slightly improve the overall time management;

- options hashTableSizeMB and gtbCacheSizeMB currently have no effect, so the defaults are always used ;

- with old WinBoard version 4.2.7b, hash table size can't be configured yet, so the default (256MB) is always used;

- the description of the "option" WinBoard command in "readme.txt" is wrong, the syntax is "option <OPTION-NAME>=<VALUE>" (the equal sign is missing).

These problems will be fixed very soon (the first three are already done), a new version will be published very soon. Many thanks to Luis Smith and Pablo Urzua for their testing efforts and for reporting these bugs!

The problem reported by Luca has not been examined yet, this is next on my list now.

Sven

[WinPooh]

Thanks, Sven. My guess is that it's about 2200.

What a rare (and pleasant) thing for these days, to look at the first version of a program which is not 2800 points or stronger

[Sven]

Thanks, Sven. My guess is that it's about 2200. [...]

What a rare (and pleasant) thing for these days, to look at the first version of a program which is not 2800 points or stronger

Although I try to approach that mark slowly from the bottom

Sven

[Sven]

I have uploaded a new version KnockOut-0.7.1-build002 that fixes some of the problems known so far (the one reported by Luca not yet since this may take longer). From the Change Log (see also the updated readme file):

Code: Select all

- fixed some time control bugs that caused several losses on time, especially
  in X+0 games and with incremental time control

- the clock adjustment triggered by the "time" WinBoard command had a severe
  problem that affected all time controls - fixing it did not only reduce the
  number of time losses but also slightly improve the overall time management

- options hashTableSizeMB and gtbCacheSizeMB did not have any effect, so the
  default settings were always used; this was corrected

- with older WinBoard GUI versions < 4.3.x, hash table size could not be
  configured yet, so the default &#40;256MB&#41; was always used; now the configuration
  file "knockout.ini" allows to overcome this problem

- the description of the "option" WinBoard command in this readme file was
  wrong, the '=' character was missing &#40;corrected&#41;

- skipped the "development" evaluation term since it was overlapping too much
  with other evaluation terms

- reduced the values for passed pawns in the opening

Any helpful hints, bug reports or tests are highly appreciated.

Sven

[Arturo Ochoa]

If nothing goes wrong while writing, this is my CCC post no. 1000

I use the opportunity to release the first beta version of my new engine "KnockOut". It is a native WinBoard engine, and I hope it is at least slightly stronger than my old engine "Surprise" which will not be maintained any longer, most probably.

There is no website yet for KnockOut. You can download the current version from here. I will announce updates in this forum, usually.

The archive also contains a "readme" where you can read all about features, options, and so on. Interesting for some may be that KnockOut can read the PolyGlot opening book format and can also access Gaviota endgame tablebases. Please refer to the "readme" for details about these features, too.

Testing volunteers are welcome

Sven

Hello :

It is very refreshing to have a new engine that has begun from scratch and not something cloned or derivative.

I have a couple of questions for you:
- Is the book used by KnockOut 0.7 a polyglot book? If so, may I provide a polyglot book for your engine?
- Will you support the analysis mode?

Note: I’m no interested in providing books for clones or derivatives or engines of doubtful origin.

Thank you.

Regards, Arturo.

[Sven]

What material values are you using? It seems to undervalue minor pieces a bit... at least it was happy to sacrifice a minor piece for 2 pawns several times and it also was happy to trade two minor pieces for a rook and a pawn, which is generally a rather bad trade.

Material values are not unusual: 325-500-975.

In fact the values are different, I replied by mind but forgot that I had changed these values some time ago. Sorry for that. The real values are 350-550-1100 for the opening and 360-550-1100 for the endgame, which is pretty much what had been recommended by Larry Kaufman some weeks ago. I tested his proposal for my engine and got a measurable improvement by that.

Regarding the problem you have reported, this is not related to material values at all but to the positional eval. In the "opening" KnockOut has chosen in your case when playing without book (1.e4 Nc6 2.d4 Nf6?! 3.e5 Nd5 4.c4 Nb4?! 5.a3 Na6 6.b4 d6?? 7.b5 +-) KnockOut currently sees several positional factors that are "good" for black (e.g. undeveloped white knights vs. one developed black knight, slightly unsafe white king, in some variations passed pawn on d4 after d6xe5 and e5xd4) and sum up to slightly more than a pawn, which is probably too much but is the current state. That explains why the material advantage of a piece minus a pawn is reduced a bit.

The major point for me, however, is that KnockOut does not see the obviously better moves, like 6...Nab8 or even 4...Nb6, which may also be an evaluation problem. To find the bug behind that may take a while.

It has high importance for me to solve that since the engine looks very "crippled" when playing like this, even if I know that it seems to happen "only" without book. There may be a severe bug somewhere.

Sven

[Sven]

The archive also contains a "readme" where you can read all about features, options, and so on. Interesting for some may be that KnockOut can read the PolyGlot opening book format and can also access Gaviota endgame tablebases. Please refer to the "readme" for details about these features, too.

It is very refreshing to have a new engine that has begun from scratch and not something cloned or derivative.

Thanks for your kind words!

I have a couple of questions for you:
- Is the book used by KnockOut 0.7 a polyglot book? If so, may I provide a polyglot book for your engine?

Yes, KnockOut can read opening books in the PolyGlot format. There is no "own book" yet. If you like you may of course create a KnockOut book. What has been good for my old engine "Surprise" for which you created the book may be good as well for the new one.

- Will you support the analysis mode?

KnockOut already supports this. Have you tried it?

For more questions about features of the engine I propose to have a look into the "readme.txt" of the current version (please note there is an update announced today within this thread).

Sven

[Dr.Wael Deeb]

I have uploaded a new version KnockOut-0.7.1-build002 that fixes some of the problems known so far (the one reported by Luca not yet since this may take longer). From the Change Log (see also the updated readme file):

Code: Select all

- fixed some time control bugs that caused several losses on time, especially
  in X+0 games and with incremental time control

- the clock adjustment triggered by the "time" WinBoard command had a severe
  problem that affected all time controls - fixing it did not only reduce the
  number of time losses but also slightly improve the overall time management

- options hashTableSizeMB and gtbCacheSizeMB did not have any effect, so the
  default settings were always used; this was corrected

- with older WinBoard GUI versions < 4.3.x, hash table size could not be
  configured yet, so the default &#40;256MB&#41; was always used; now the configuration
  file "knockout.ini" allows to overcome this problem

- the description of the "option" WinBoard command in this readme file was
  wrong, the '=' character was missing &#40;corrected&#41;

- skipped the "development" evaluation term since it was overlapping too much
  with other evaluation terms

- reduced the values for passed pawns in the opening

Any helpful hints, bug reports or tests are highly appreciated.

Sven

Thanks Sven,that was a quicky,much appreciated....
Dr.D

[metax]

In fact the values are different, I replied by mind but forgot that I had changed these values some time ago. Sorry for that. The real values are 350-550-1100 for the opening and 360-550-1100 for the endgame, which is pretty much what had been recommended by Larry Kaufman some weeks ago. I tested his proposal for my engine and got a measurable improvement by that.

Regarding the problem you have reported, this is not related to material values at all but to the positional eval. In the "opening" KnockOut has chosen in your case when playing without book (1.e4 Nc6 2.d4 Nf6?! 3.e5 Nd5 4.c4 Nb4?! 5.a3 Na6 6.b4 d6?? 7.b5 +-) KnockOut currently sees several positional factors that are "good" for black (e.g. undeveloped white knights vs. one developed black knight, slightly unsafe white king, in some variations passed pawn on d4 after d6xe5 and e5xd4) and sum up to slightly more than a pawn, which is probably too much but is the current state. That explains why the material advantage of a piece minus a pawn is reduced a bit.

The major point for me, however, is that KnockOut does not see the obviously better moves, like 6...Nab8 or even 4...Nb6, which may also be an evaluation problem. To find the bug behind that may take a while.

It has high importance for me to solve that since the engine looks very "crippled" when playing like this, even if I know that it seems to happen "only" without book. There may be a severe bug somewhere.

Sven

I had similar problems, too, when I began writing ChessMind. It was valuing some piece sacrifices too high... In most cases, the positional eval was simply exaggerated because I thought of values and eval terms that might be beneficial (because I had hardly any testing resources) but my estimations were very imprecise... After looking at the subdivided eval for the positions that were evaluated too high for the side that had one or two pawns for a minor piece, it was usually obvious which evaluation term was way too high.
Obviously, my engine still isn't playing positionally strong chess, but at least it doesn't sacrifice minor pieces without any reason.