UCI Engine Tuning

[Roger Brown]

It's not ~just~ the effort of coding xboard dynamic config support. Scid is a huge sprawling project, and I've started to not add code/features just to avoid more bloat. For good or bad, UCI seems the prevalent protocol.



And I will mention Scid's engine configuration does allow for command line options to be given to the engine, which many engines support.

Hello Steven,

By any measure, Xboard/Winboard protocol based engines are prevalent.

Most engines support that protocol. I am not arguing what you do with Scid, I quite like the development, but I thought I would correct this inaccuracy.

Later.

[stevenaaus]

Please let me, know, I am very interested to make sure there are not protocol issues. I put a lot of effort to make sure Gaviota work in every single GUI I and many others tested for both, UCI and winboard.

Ok.. i booted up my AMD64 (Fedora14!) system, and Gaviota 0.83 runs nicely on Scid vs. PC's tournament in UCI mode.

Xboard mode + Tournament still doesn't work (Analysis seems fine)... Maybe i'll try to debug it one day, or you're welcome to do so. The tournament feature prints it output to the console in Linux, or you can also examine the engine logs in Scid-Vs-PC/bin/log. Scid vs. PC's xboard support probably needs work.

I am not sure what you mean by getting more than one move, but if you try to send several "go" you need to send "force" (I think, I do not remember this detail from memory). i.e. you cannot change sides w/o using force IIRC.

Hmmm.. I don't try to change sides. When it is Gaviota's turn, i send a "setboard" "level" and "go". It makes the first move, but not a second:

2 setboard rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - 0 1
2 level 0 1:0 1
2 go
ENGINE 2 says: 1 18 0 30 Nf6
ENGINE 2 says: 2 -7 0 105 Nf6 2.Nc3
ENGINE 2 says: 3 18 0 289 Nf6 2.Nc3 Nc6
ENGINE 2 says: 4 16 0 2167 d5 2.e5 Nc6 3.d4
ENGINE 2 says: 5 11 1 7661 Nc6 2.Nc3 Nf6 3.Nf3 d6
ENGINE 2 says: 6 1 4 20009 Nc6 2.d4 d5 3.e5 Bf5 4.Nc3
ENGINE 2 says: 7 14 14 68213 d6 2.Nc3 Nf6 3.Nf3 Nc6 4.Bb5 Bg4
ENGINE 2 says: 8 0 18 85791 d6 2.Nc3 Nf6 3.Nf3 Nc6 4.h3 Be6 5.Bb5
ENGINE 2 says: 8 0 22 107642 d6 2.Nc3 Nf6 3.Nf3 Nc6 4.h3 Be6 5.Bb5
ENGINE 2 says: 9 -4 31 150223 d6 2.Nc3 Nf6 3.Nf3 Nc6 4.d4 Bg4 5.h3 Be6
ENGINE 2 says: 9 7 57 276828 d5 2.exd5 Qxd5 3.Nc3 Qe6+ 4.Be2 Nf6 5.d4 Qd6 6.Bb5+ c6 7.Bc4
ENGINE 2 says: 9 7 61 295080 d5 2.exd5 Qxd5 3.Nc3 Qe6+ 4.Be2 Nf6 5.d4 Qd6 6.Bb5+ c6 7.Bc4
ENGINE 2 says: 10 -4 97 464277 d5 2.exd5 Qxd5 3.Nc3 Qd6 4.Nf3 Nf6 5.d4 Nc6 6.d5 Nb4 7.Bb5+ Bd7
ENGINE 2 says: 10 -4 151 714900 d5 2.exd5 Qxd5 3.Nc3 Qd6 4.Nf3 Nf6 5.d4 Nc6 6.d5 Nb4 7.Bb5+ Bd7
ENGINE 2 says: 11 -4 266 1247630 d5 2.exd5 Qxd5 3.Nc3 Qe6+ 4.Be2 Qg6 5.Bf3 Qd6 6.d3 Nc6 7.Nge2 Nf6
ENGINE 2 says: move d7d5

and then after the opponent has moved, gaviota wont make a second move

2 setboard rnbqkbnr/ppp1pppp/8/3P4/8/8/PPPP1PPP/RNBQKBNR b KQkq - 0 2
2 level 0 0:57 1
2 go

and no output is received

[hgm]

This is not standard use of XBoard protocol, and although the specs do not explicitly forbid it, I would not be surprised if many engines cannot handle it. In particular sending a 'level' command after setboard is something no existing GUI (to my knowledge) would do. The time and otim commands are intended to inform the enginesof the new clock time (and they have centi-sec precision, rather than integer seconds).

Normally, you would just send the opponent's move to the engine:

e4d5

or

usermove e4d5

Not a new setboard. Many engines would think that a setboard starts a new game, and clear their hash tables (which can take a long time, if these are big). It would almost certainly annihilate any effect of pondering. Some engines don't support any way of setting up a position(neither setboard, nor edit). Yet on most GUIs they can play games from the standard opening position without problems.

None of this is an excuse for Gaviota not responding, though.

[michiguel]

This is not standard use of XBoard protocol, and although the specs do not explicitly forbid it, I would not be surprised if many engines cannot handle it. In particular sending a 'level' command after setboard is something no existing GUI (to my knowledge) would do. The time and otim commands are intended to inform the enginesof the new clock time (and they have centi-sec precision, rather than integer seconds).

Normally, you would just send the opponent's move to the engine:

e4d5

or

usermove e4d5

Not a new setboard. Many engines would think that a setboard starts a new game, and clear their hash tables (which can take a long time, if these are big). It would almost certainly annihilate any effect of pondering. Some engines don't support any way of setting up a position(neither setboard, nor edit). Yet on most GUIs they can play games from the standard opening position without problems.

None of this is an excuse for Gaviota not responding, though.

Correct. I fixed the silly problem. Thanks! I lacked a line in the setboard routine that I failed to copy and paste from other routines. It went undetected because it was never tested this way.

Anyway, receiving setboard for each move will screw Gaviota, because it will not remember the hashtables or previous moves, missing 3-reps.

Miguel

[stevenaaus]

Anyway, receiving setboard for each move will screw Gaviota, because it will not remember the hashtables or previous moves, missing 3-reps.

Hmmm... on UCI i do the same thing.

Code: Select all

position fen rnbqkbnr/pppp1ppp/8/4p3/4P3/8/PPPP1PPP/RNBQKBNR w KQkq - 0 2
go wtime 55857 btime 58611 winc 1000 binc 1000

But i gather there is no better alternative on UCI ?

[Michel]

Hmmm... on UCI i do the same thing.
Code:
position fen rnbqkbnr/pppp1ppp/8/4p3/4P3/8/PPPP1PPP/RNBQKBNR w KQkq - 0 2
go wtime 55857 btime 58611 winc 1000 binc 1000

But i gather there is no better alternative on UCI ?

The correct way to do this in UCI is

Code: Select all

position startpos moves ....
...

When using "position fen" the engine cannot handle 3-fold repetition correctly.

[stevenaaus]

Cheers for that.
I've changed the Xboard and UCI commands in Scid vs. PC subversion, and am coming to grips with it. Some engines are better, but some old ones still misbehave.

One thing i noticed... Scid's move string can have a move like "e2e1Q" but the uppercase Q crashed some uci engines and i had to lowercase this. I thought the promotion piece was meant to be uppercase ?

And fairymax leaves out the promotion piece altogether ? ... Bad.

[Michel]

I thought the promotion piece was meant to be uppercase ?

It has to be lowercase in both UCI and in xboard long algebraic notation.
In xboard short algebraic notation it has to be uppercase.

[stevenaaus]

I thought the promotion piece was meant to be uppercase ?

It has to be lowercase in both UCI and in xboard long algebraic notation.
In xboard short algebraic notation it has to be uppercase.

You're not making things any easier for me, laugh.

I just ran some quick tests... Komodo 2.03 and Ivanhoe seem significantly stronger now i'm not using setfen.

[Don]

I thought the promotion piece was meant to be uppercase ?

It has to be lowercase in both UCI and in xboard long algebraic notation.
In xboard short algebraic notation it has to be uppercase.

Isn't it annoying that you always get some random program that breaks a standard - and then you face a dilemma about whether to support their broken version of the standard or not. When you do more programs will "work" but you also encourage a relaxation of the standard.

There is a philosophy about this which basically says to be as forgiving as possible about what comes in, but be strict and conforming about what goes out. For UCI that would mean build GUI's and tools that accept it either way. That philosophy is reasonable, but it does tend to encourage people to be sloppy when implementing stuff. A message should pop up which says, "non-conforming implementation - compensating ..."