Winboard Forum

Hi,

New version of Naum is ready for download.
It has improved history pruning. Once I made history pruning work better, I was able to make it more aggresive without too many negative effects.
I also added more futility pruning. This change has made Naum stronger, but somewhat unpredictable.
There are also changes in q-search checks that made Naum play tacticaly better. This version should produce less draws.

You will also find two FRC versions. One is the unchanged version that played in Mainz. Second one is the 2.0 FRC version. I think that 2.0 is better than Mainz, but I could be wrong.
You can also try the FRC versions in regular chess, but they will be slower and I think weaker. They have a different playing style (more positionaly aggresive). I tried some of my FRC evaluation changes in a regular version, but none of them worked. This is why I have a separate FRC version for now.

I was thinking of quiting the comp chess after this version, but I have found a new inspiration. I decided to rewrite both search and evaluation. The main goal is to create a simplified version and then start adding many features I currently have in Naum. Over time, I have added many things and they started to interact with one another in unexpected and unpredictable ways. This is the reason to start fresh. I already have a simplified version of search and it doesn't seem to be much weaker than my current one. This is great, because the new simplified search has a lot of room for further improvements. I also have an idea for the evaluation feature that will enable me to add some knowledge without any coding, but this will take some time to implement.

Have fun,
Alex

Thanks Alex and keep up the good work!

Naum wrote:Hi,

New version of Naum is ready for download.
It has improved history pruning. Once I made history pruning work better, I was able to make it more aggresive without too many negative effects.
I also added more futility pruning. This change has made Naum stronger, but somewhat unpredictable.
There are also changes in q-search checks that made Naum play tacticaly better. This version should produce less draws.

You will also find two FRC versions. One is the unchanged version that played in Mainz. Second one is the 2.0 FRC version. I think that 2.0 is better than Mainz, but I could be wrong.
You can also try the FRC versions in regular chess, but they will be slower and I think weaker. They have a different playing style (more positionaly aggresive). I tried some of my FRC evaluation changes in a regular version, but none of them worked. This is why I have a separate FRC version for now.

I was thinking of quiting the comp chess after this version, but I have found a new inspiration. I decided to rewrite both search and evaluation. The main goal is to create a simplified version and then start adding many features I currently have in Naum. Over time, I have added many things and they started to interact with one another in unexpected and unpredictable ways. This is the reason to start fresh. I already have a simplified version of search and it doesn't seem to be much weaker than my current one. This is great, because the new simplified search has a lot of room for further improvements. I also have an idea for the evaluation feature that will enable me to add some knowledge without any coding, but this will take some time to implement.

Have fun,
Alex

Your idea of a rewrite (due to code becoming unweildy over time) is a very good one, and several other chess authors I know of have followed this exact path and had good results.

A classical example is Tord's Glaurung project {which followed gothmog}

I am sure that the new iteration will be even stronger. Naum is already of commercial quality and something to be proud of.

Naum wrote:...
There are also changes in q-search checks that made Naum play tacticaly better. This version should produce less draws.
...

Hi,
I will test Naum 2.0 as soon as possible in YABRL (currently Pharaon and Scorpio running, though, which will take 20+ days). It will be interesting to see, whether the draw percentage indeed drops.
In fact I have already observed with several engines (e.g. ChessTiger, List, Spike and Naum) that they produce more draws than others, although I could never really determine which characteristic makes an engine a "drawer". What do you think will make Naum produce fewer draws now?

Robert

Your idea of a rewrite (due to code becoming unweildy over time) is a very good one, and several other chess authors I know of have followed this exact path and had good results.

A classical example is Tord's Glaurung project {which followed gothmog}

I am sure that the new iteration will be even stronger. Naum is already of commercial quality and something to be proud of.

Thanks Dann. Yes it seems to be a good idea. I am tuning the basic features now. For instance, by optimizing move ordering, switching to pc-toSq indexing instead of the fromSq-toSq for history and by adding another TT entry, I was able to reduce by around 25% the number of nodes needed for a depth. Now I am sorry I didn't put those changes into the 2.0 version.

I will test Naum 2.0 as soon as possible in YABRL (currently Pharaon and Scorpio running, though, which will take 20+ days). It will be interesting to see, whether the draw percentage indeed drops.
In fact I have already observed with several engines (e.g. ChessTiger, List, Spike and Naum) that they produce more draws than others, although I could never really determine which characteristic makes an engine a "drawer". What do you think will make Naum produce fewer draws now?

Hi Robert,
I am looking forward to your testing.
As far as I could see, Naum started producing less draws once I added checks in the q-search. This improved the tactical vision.
The new futility pruning also seems to cause less draws, because it makes Naum more 'adventurous'. Old version had much more conservative pruning.

Naum wrote:...
As far as I could see, Naum started producing less draws once I added checks in the q-search. This improved the tactical vision.
The new futility pruning also seems to cause less draws, because it makes Naum more 'adventurous'. Old version had much more conservative pruning.
...

So risk-taking eliminates draws. It "just" has to work more often than not, which is probably the difficult part in it ...

Robert

Naum wrote:...
You will also find two FRC versions. One is the unchanged version that played in Mainz. Second one is the 2.0 FRC version....

Thanks a lot for the programs. I'll test them soon.

Does the FRC version work as winboard engine? I doubt it:

Code: Select all

volker:~/schach/naum> wine naum_frc
Naum 2.0 FRC
Copyright (C) 2003-2006  Aleksandar Naumov

xboard
feature done=0
Memory Usage:
    Transposition Table: 24640 KB
    Pawn Hash          : 1120 KB
    Endgame Tablebase  : 2 MB

EGTB Status: Maximum 4 piece tablebases found

feature ping=1 setboard=1 san=0 time=1 draw=0
feature sigint=0 sigterm=0 reuse=1 analyze=1
feature myname="Naum 2.0 FRC" name=1
feature playother=1 colors=0
feature variants="normal"  <==== ???
feature done=1


Hi Volker,

why don't you try "uci" and look at the options. ?

Best,
Daniel

Daniel Mehrmann wrote:Hi Volker,

why don't you try "uci" and look at the options. ?

Best,
Daniel

I'll do if I test the frc version.

This way the possible bug will be corrected magically

Volker

Hi Volker,

FRC works only in the UCI mode. You could always use the Polyglot if you want to run it under WB.
I tested the FRC version under Arena 1.1 only. I know for sure it doesn't work under Shredder Classic (can't understand why SMK decided to re-invent the wheel).

Alex

Naum wrote:Hi Volker,

FRC works only in the UCI mode. You could always use the Polyglot if you want to run it under WB...

Thanks. I'll try it soon. I'm thinking about a good test setup for FRC. The version for "normal" chess works fine with wine under linux and performed well here:

Code: Select all

Rank Name                                      Elo    +    - games score oppo. draws
   1 Spike 1.2 Turin                          2854   27   26   960   85%  2421   12%
   2 Fruit-Toga 1.2.1                         2837   59   55   200   84%  2416   13%
   3 Rybka 1.0 beta 32 bit                    2779   57   54   200   79%  2416   10%
   3 Glaurung 1.2.1                           2777   57   54   200   80%  2416   13%
   5 Naum 2.0                                 2772   56   53   200   79%  2416   12%
   6 Fruit 2.1                                2755   25   25   960   77%  2423   11%
   7 Shredder Classic 1.3                     2751   53   51   200   78%  2416   17%
   8 Ruffian 2.1.0                            2718   53   51   200   74%  2416   14%
   9 Glaurung 1.2                             2714   54   52   200   75%  2416   13%
  10 Pharaon 3.5                              2705   52   50   200   74%  2416   17%
  11 Colossus 2006f                           2660   50   49   200   70%  2416   18%
  12 Scorpio 1.8                              2637   52   51   200   68%  2416   12%


Test conditons look here.

Naum wrote:I tested the FRC version under Arena 1.1 only...

Uh oh, let's hope it works with xboard too. Arena does not work properly under wine/linux.

Naum wrote:I know for sure it doesn't work under Shredder Classic (can't understand why SMK decided to re-invent the wheel).

Alex

The confusion about the different notation styles are a big handicap for FRC. However, the discussion about it took place between grown-up people. Unfortunately some characteristics of that discussion have been ignorance on the one side and obstinacy on the other.

Nothing unusual in this world and in online forums in particular, but a nuisance in any case.

Volker

Naum wrote:...I tested the FRC version under Arena 1.1 only...

Volker Pittlik wrote:...Uh oh, let's hope it works with xboard too. Arena does not work properly under wine/linux...

It doesn't .

No need to hurry to change it for me. I'm going to test other things in the next time.

Volker

Volker Pittlik wrote:...
It doesn't .
...

Whatever is going wrong I cannot solve it. I even don't understand the error message:

Code: Select all

< ENGINE info currmove O-O currmovenumber 1 nodes 113843 nps 98055
< ENGINE info score cp -11 depth 10 seldepth 23 time 1724 nodes 200658 nps 116390 pv O-O d2d3 d7d6 d1c3 d8e6 h1e4 c8d7 b3a5 e6c5 e4d5
> XBOARD 10 -11 172 200658
< ENGINE info currmove d7d6 currmovenumber 2 nodes 200658 nps 116323
< ENGINE info currmove g7g6 currmovenumber 3 nodes 206679 nps 112386
< ENGINE info currmove d8c6 currmovenumber 4 nodes 210457 nps 113699
< ENGINE info currmove d8e6 currmovenumber 5 nodes 212599 nps 114485
< ENGINE info currmove a8b6 currmovenumber 6 nodes 214824 nps 115248
< ENGINE info currmove d7d5 currmovenumber 7 nodes 224944 nps 115711
< ENGINE info currmove f7f5 currmovenumber 8 nodes 226791 nps 116303
< ENGINE info currmove e8e6 currmovenumber 9 nodes 232228 nps 117942
< ENGINE info currmove c7c6 currmovenumber 10 nodes 235601 nps 116231
< ENGINE info currmove h7h5 currmovenumber 11 nodes 250232 nps 117811
< ENGINE info currmove c7c5 currmovenumber 12 nodes 252323 nps 118350
< ENGINE info currmove g7g5 currmovenumber 13 nodes 274841 nps 122314
< ENGINE info currmove b7b5 currmovenumber 14 nodes 275620 nps 122497
< ENGINE info currmove e5e4 currmovenumber 15 nodes 278756 nps 123397
< ENGINE info currmove f7f6 currmovenumber 16 nodes 283109 nps 121924
< ENGINE info currmove b7b6 currmovenumber 17 nodes 283326 nps 122018
< ENGINE info currmove a7a5 currmovenumber 18 nodes 290386 nps 123937
< ENGINE info currmove a7a6 currmovenumber 19 nodes 295465 nps 125250
< ENGINE info currmove h7h6 currmovenumber 20 nodes 297851 nps 123333
< ENGINE info currmove f8e7 currmovenumber 21 nodes 300264 nps 123922
< ENGINE info currmove e8e7 currmovenumber 22 nodes 301008 nps 124075
< ENGINE bestmove O-O ponder d2d3
parse_bestmove(): not a move "O-O"
POLYGLOT *** QUIT ***
> ENGINE quit
< ENGINE EOF


Volker

Hi,
I took a look at the Polyglot/WB combination for FRC. It won't work. Polyglot also supports only Shredder-FRC.
Naum actually supports Shredder-FEN. The problem seems to be that Shredder Classic and Polyglot don't accept O-O as a valid castling move. They expect castling move to be in the 'king takes rook' form.
Alessandro's WB also seem to have a bug. It's always sending to Polyglot the regular chess start position instead of the choosen FRC position.
I may add full support for Shredder-FRC in the future, but it's at the bottom of my todo list.

Alex

Hello,

I often run engines in ChessProgram8.exe, using wine on a Linux system.
After some fiddling around this works really fine and nearly all Windows exes run, and with good performance.
Naum does not, and i think it was for the last some versions that this is the case.
When i run the naum.exe in the bash using wine it starts and everything is fine, it reacts to the "uci" - command and there seems to be no problem.

But neither in ChessProgram8.exe nor in different versions of Arena Naum can be loaded properly, in both environments it does not even start playing, and in CB it is not even possible to create a uci engine.

Does anybody have a similar problem and can give me a little hint?
(More technical info about my system can be given, but i think the problem should be clear)
I have played with Naum from the very early versions on, so any help would be appreciated.

regards
Peter

Peter Eizenhammer wrote:Hello,

I often run engines in ChessProgram8.exe, using wine on a Linux system.
After some fiddling around this works really fine and nearly all Windows exes run, and with good performance.
Naum does not, and i think it was for the last some versions that this is the case....

All this sounds very strange. Sorry, I have lost lots of data because my computer crashed, but IIRC I was never able to run any CB program with wine on Linux. Some windows only executables (including Naum) run very good with the help of wine. There where only a very few which didn't. Queen for example which requires certain DLLs.

I'm aware of other Windows programs (not related to chess) which sometimes run under wine, sometimes they do not. Sometimes it depends on the wine version, sometimes on the Linux distribution/kernel version/processor/phase of the moon.

If it is not a terminal program it seems to be a "Gefrickel" (I have no translation for that) most of the times. OTOH Andrew's WBRGO runs without any problem.

Volker

Hi Peter,

Starting with version 1.91, I changed my I/O routines (reading user input) to use Windows APIs only.
Maybe that has something to do with your problem.

Regards,
Alex

Hi Alex! I just wanted to say that I was testing Naum 2.0 for the last month against other top free engines. As it seems now (combined with the result of other testers), Naum 2.0 holds solid 4-th place in CCRL 40/40 free single-CPU list.

Top 12 quote:

Code: Select all

 Rank             Engine               ELO   +    -  Score AvOp Games
    1 Rybka 1.0 64-bit                2920   17  -17  69%  -131  1211
    2 Toga II 1.2.1a                  2871   15  -15  50%    -8  1489
    3 Spike 1.2 Turin                 2847   16  -16  50%    -5  1381
    4 Naum 2.0 32-bit                 2810   22  -22  51%    -4   679
    5 Glaurung 1.2.1 64-bit           2772   24  -24  45%    29   556
    6 Scorpio 1.8                     2752   20  -20  47%    15   778
    7 Slow Chess Blitz WV2.1          2744   17  -17  48%     9  1094
    8 Zappa 1.1 64-bit                2742   28  -28  45%    33   414
    9 List 5.12                       2727   21  -21  47%    19   756
10-11 Pharaon 3.5.1                   2717   21  -21  43%    48   752
10-11 Ruffian 1.0.5                   2717   22  -22  45%    26   670
   12 Delfi 5.0                       2710   22  -22  47%    13   650


This is great step up from the previous version! Thanks for your work and please don't stop!

Free single-CPU list
Comparison of Naum versions

Best,
Kirill

Hello Volker,

I think (and can be totally wrong of course), that the reason why naum works in text only mode, while it does not work in cooperation with a gui (using wine on linux) is, that Namu does use a some strange or rare or very advanced method, function for communicating the uci commands to the gui and vice versa.
(To say it again: IT d o e s work for practically every engine, of course some are problematic on Windows, too, so we can ignore these.)
So if Alexander reads this, he may know at once, what could be the reason (something that cannot be performed by wine). (hello?

Some more words about wine and CB programs:
You are certainly right that these programs do usually not work out of the box in a unmodified wine environment.
I had to modify some details to make it work for me, and as you say, there are many things that can have effects, including the weather.

But nevertheless:
- To have some good true type fonts available is an advantage for many programs: One can install them via konqueror, if on has kde installed, or try to copy the fonts to the corresponding font directory of the existing wine installation, usually in the home directory. For the latter method it may be necessary to register the fonts, what can be done manually by inserting keys into the registry; i dont remember exactly in the moment, i could check it, if you need it.

- To have an existing windows is good, too, and is not a puristic solution, of course; it is not real wine only any longer, if one uses real windows dlls to complement or substitute the wine dlls.
There are different issues, if this makes sense: Security, legal aspects, ... I chose I want it, and used my existing windows, ymmv.

- There are the "winetools", which do quite some changes and are issue of discussion: Again it is not pure wine.
I used them up to the point, where the winetools want to install the IE, what I did not want as it seemed to much of a security problem to me, again ymmv.

-When one tries to run a windows program it is easiest to do it from bash (or what you use), typing "wine x.exe". (When it comes to additional options there are the usual problems about masquerading the command string, but just try the usual suspects ' " ` .)
The advantage is, that one can read what goes wrong, and what dll or similar was not found, as wine puts out some debug info.

Often it takes only the transfer of a single dll from your real windows and everything works fine , as the needed functionality exists now.
I think there were some of them necessary to make ChessProgram8.exe work, and CB8 itself works, too, after some "Gefrickel", but it is certainly not a "pure" method and discussable; but as an experienced user one can decide if one wants to choose this way, while the risks and problems are probably not to recommend for most people.

BTW: the wine versions 0.9.24 and 0.9.25 were flawed as far i can say, but with 0.9.26 things run fine again.

Peter

Hello Alex,

thanks for your quick answer!
Yes, the io - change you mention is very likely to be the reason for this problem.
If I knew in what windows dll the api function you call is based, then I could probably solve it. I think you are not thinking about a change, as the problem is very specific to few users, but well, thanks for your great (as I hear ) engine.

regards
Peter

(p.s.: sorry i had written the long answer to Volker before i had noticed your answer, so there is a little inconsistency.)