Winboard Forum

Hi all,

As some of you may have noticed already, Glaurung 1.0 is available since last night (European time). You will find source code and binaries for Mac OS X, Linux and Windows on my Glaurung and Scatha page. Please observe that the opening book format has changed; the book from Glaurung Mainz and older versions will not work. If you downloaded Glaurung 1.0 beta 1 and it's book, you've got the right one.

The following are the main changes compared to Glaurung Mainz:

• Static null move pruning added. I used this in the first few versions of Glaurung, but removed it about a year ago because it didn't seem to help. Now it suddenly does seem to help (don't ask me why), so I put it back.
• Reductions are now based on evaluation data rather than history counters.
• A serious hash table bug which would sometimes cause hash table entries to contain incorrect search depths has been fixed.
• Evaluation weights for aggressiveness, mobility and passed pawns have been increased. A big thanks to Roger Brown, who ran several long tests with various king safety settings and helped me discover that it was possible to use insanely high king safety weights without seriously hurting playing strength.
• Several minor bug fixes in the search and evaluation.
• New opening book format, and a new and improved (I hope) opening book.
• Several new UCI parameters for tuning the search and eval.
• MultiPV mode.
• Almost full support for the "go" UCI command. Glaurung now understands the "movetime", "nodes", "depth" and "searchmoves" parameters. The only thing still missing is mate searches.

Compared to Glaurung 1.0 beta 1, which was released a few days ago, I've made the following changes:

• By default, static null move pruning is now done when the remaining depth is 2 plies or less, rather than 1 ply or less (as in 1.0 beta 1). This was a very difficult decision to make, and I fear that I may end up regretting it. My intuition tells me that 2 plies of static pruning is too risky, but so far 2 plies have scored slightly better than 1 ply in games as well as test suites. The results are almost, but not quite, statistically significant. If somebody has some CPU time to waste, I would love to see a thorough comparison of 1 ply vs 2 plies of static null move pruning.
• 1.0 beta 1 would always use its own book, even if the "OwnBook" UCI parameter was false. Fixed in 1.0. Thanks to Wilhelm Hudetz for reporting this bug.
• 1.0 beta 1 crashed whenever it was sent a "setoption" command with a non-existing option. Fixed in 1.0. Thanks to Peter Eizenhammer for reporting this bug.
• Fixed a bug which slowed down the search considerably in MultiPV mode.
• Added a new UCI parameter, "Checks in quiescence search", for controlling the number of plies of checks allowed in the qsearch. The default value is 3, but it is possible that 1 ply is better.

Enough of the boring technical details. To me, the most exciting thing about this version is that it has a much more active, daring and enterprising style than its predecessors, and is more fun to watch and play against. Those who miss the wild attacks and clownish sacrifices of Gothmog (my old engine) will probably be very happy with Glaurung 1.0.

Have fun!

Tord

Tord Romstad wrote:...

[*]Reductions are now based on evaluation data rather than history counters.

...

This sounds rather novel to me, at least something like this cannot be found in many engines AFAIK. May I ask you to please explain a bit this idea in more detail?


With respect to compilation:
I saw that there was a speed discussion in CCC, related to 64 bit etc. In this context, is this 1.0 executable of comparable compilation quality as the Glaurung Mainz release or can we expect faster compilations by the gurus popping up here and there? I am asking from the tester's perspective ...

Thanks
Robert

Robert Allgeuer wrote:

Tord Romstad wrote:...

[*]Reductions are now based on evaluation data rather than history counters.

...

This sounds rather novel to me, at least something like this cannot be found in many engines AFAIK. May I ask you to please explain a bit this idea in more detail?

Sure. It isn't really novel; I used it in Gothmog and have described it on the Chess and Curling Club a few times over the past two years. You are probably right that it is not very commonly used, though.

The idea is rather simple and obvious: When a move is a candidate for reduction (i.e. being searched with less than full depth), I check how this move affects the evaluation function. If the move does not hang a piece and it increases the evaluation, I avoid reducing the move. Also, even if the move does not increase the evaluation, I avoid reducing it if it dramatically increases the passed pawn score for the side to move, or if it increases the pressure against the opponent king sufficiently much.

The above was a rather non-technical and somewhat imprecise description of what I do. Programmers who are interested in the precise implementation details are adviced to look at my source code.

Thanks to Anthony Cozzie, who convinced me to try evaluation-based reductions again. I would have experimented with them sooner or later in any case, but without Anthony's advice I would probably have waited a few months longer.

With respect to compilation:
I saw that there was a speed discussion in CCC, related to 64 bit etc. In this context, is this 1.0 executable of comparable compilation quality as the Glaurung Mainz release or can we expect faster compilations by the gurus popping up here and there? I am asking from the tester's perspective ...

Hard to say. The executable on my home page was compiled by Dann Corbit. Perhaps Bryan will provide us with a faster binary later.

At any rate, I don't think we can expect to see a much faster executable. And even if Bryan or somebody else is able to squeeze out another 10% speed, this translates to less than 10 Elo points.

Tord

Tord Romstad wrote:Hi all,


<snipped>

[*]Reductions are now based on evaluation data rather than history counters.

[*]By default, static null move pruning is now done when the remaining depth is 2 plies or less, rather than 1 ply or less (as in 1.0 beta 1). This was a very difficult decision to make, and I fear that I may end up regretting it. My intuition tells me that 2 plies of static pruning is too risky, but so far 2 plies have scored slightly better than 1 ply in games as well as test suites. The results are almost, but not quite, statistically significant. If somebody has some CPU time to waste, I would love to see a thorough comparison of 1 ply vs 2 plies of static null move pruning.

Tord

1)How much does glaurung earn from reduction based on evaluation data.

There is no parameter in glaurung to disable these reductions so I guess that people who want to test it need to change the source for that purpose.

2)The default parameter of static null move pruning under chessbase gui is 1 and not 2.

I wonder if there is no mistake there and it should be 2

Uri

Uri Blass wrote:1)How much does glaurung earn from reduction based on evaluation data.

I don't know. My tests only give a probability that version A is better than version B, they don't give any estimated rating difference. I think the new extension scheme is the most important improvement compared to Glaurung Mainz, though.

This does not mean that the new reduction scheme is very good. Actually I think it is very far from optimal, and that it would be possible (but by no means easy) to improve the strength by 50-100 points just by improving this.

There is no parameter in glaurung to disable these reductions so I guess that people who want to test it need to change the source for that purpose.

Perhaps there should be such a parameter. Disabling the reductions by changing the source is easy: The only thing you need to do is to change the ok_to_reduce() function to always return 0.

2)The default parameter of static null move pruning under chessbase gui is 1 and not 2.

Oops, you are right! That's an incredible mistake on my part. It seems I only changed my PolyGlot init file, and forgot to enter the new value in the source code.

I think this mistake is too minor to justify the release of a 1.01 version. I will just advice all testers to change the value of the "Static pruning depth" parameter from 1 to 2.

Tord