ScidVsPC/Mac

[JuLieN]

Yes - very my bad
Here's my best 32 bit engines at 12 seconds + 0

Code: Select all

Ponder
?, 2012.03.13
                     Score        1    2    3    4    5    6
-------------------------------------------------------------
 1: Strelka 5      15.5 / 20   XXXX 0110 1110 11== 1=11 1111
 2: Stockfish 2.2  12.5 / 20   1001 XXXX 1000 ==11 1011 111=
 3: Scorpio        11.5 / 20   0001 0111 XXXX 1=11 =010 1=01
 4: Critter         9.5 / 20   00== ==00 0=00 XXXX 1111 1011
 5: Komodo 2.03     5.5 / 20   0=00 0100 =101 0000 XXXX 0=01
 6: Robbo           5.5 / 20   0000 000= 0=10 0100 1=10 XXXX
-------------------------------------------------------------
60 games: +30 =10 -20

That's ok, everyone has his blonde moments* ^^

By the way, what are you playing those tournaments with? Windows, Linux, OSX?

*sorry

[stevenaaus]

I use Fedora7 exclusively really, but have Linux Mint 10, Fedora 14 (amd64) , OSX 10.5.8 , winXP an FreeBSD 7 systems too.

I'm starting to think that some sort of adjudication is helpful.
Mainly for materially drawn games (eg opposing coloured bishops)are generally lost on time by one engine. But I definitely don't like arena's form of adjudication.

I think it's fair, but not practical, for admin to scan through played games and make adjudications on any issues they see as relevant.

I wonder if i can hack the browse game feature to allow for altering the game result without affecting an ongoing tournament.
Maybe I'll look at coding this tonight.

[JuLieN]

Steven, new problem since I compiled your modifications: when I let an engine analyze a position and click on the "information" button of the analyze window I get a 'Error: invalid command name "at" ' popup.

To reproduce it:
1- Edit/paste starting position
2- Tools/analysis engine
3- SCID analysis Engine window -> "position"
4- SCID's engine's window: "i"

More details about the crash:

Code: Select all

invalid command name "at"
invalid command name "at"
    while executing
"at inert end "Hash: $::uci::uciInfo(hashfull$n)  ""
    (procedure "updateAnalysisText" line 49)
    invoked from within
"updateAnalysisText $n"
    (procedure "toggleEngineInfo" line 11)
    invoked from within
"toggleEngineInfo 15"
    invoked from within
".analysisWin15.b.showinfo invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tk::ButtonUp" line 23)
    invoked from within
"tk::ButtonUp .analysisWin15.b.showinfo"
    (command bound to event)

[stevenaaus]

Yeah - that gremlin had already been fixed.

I'm going to make the move time-out feature automatic.... (and for today it is disabled).

But how much lee-way should i give an engine in time-per-move games and time-per-game ? I'm thinking

per-game: Time remaining for game + 2 seconds
per-move: Time remaining for move + 2 seconds (which is quite generous i think).

[JuLieN]

Yeah - that gremlin had already been fixed.

I'm going to make the move time-out feature automatic.... (and for today it is disabled).

But how much lee-way should i give an engine in time-per-move games and time-per-game ? I'm thinking

per-game: Time remaining for game + 2 seconds
per-move: Time remaining for move + 2 seconds (which is quite generous i think).

I think only HGM could answer this question, as most engine authors are totally unaware of what's going on from the GUI's point of view... But 2s/move seems like a lot: a GUI shouldn't steal less than a few micro-seconds per move, I think...

[stevenaaus]

I really should get to bed earlier, but i've coded this. Move timeouts should now be automatic.

I think only HGM could answer this question, as most engine authors are totally unaware of what's going on from the GUI's point of view... But 2s/move seems like a lot: a GUI shouldn't steal less than a few micro-seconds per move, I think...

Yes.
ScidvsPC's tourney time management is pretty good i think. It's probably more than Xboard (et-al), but imho should be very small because of careful tournament loop construction and time calculation.

The 2 seconds (set comp(delta) 2000) timeouts are currently for both time-pre-game and time-per-move tourneys, but are not indicative of any lag period. I believe one can set this to .1 second (100), .01 second (10) , or even zero, and it should still work perfectly. But i don't want to be so stingy that games are lost because an engine takes .11 seconds for a move instead of .1 seconds. The flat two seconds is just a generous working value.

BTW, In per-game times, the tolerance is still zero regardless of what one sets comp(delta) to. If an engine uses it's alotted time, it loses. This timeout is merely a safeguard against engines hanging. Testing appreciated.

[stevenaaus]

Hmmm....made some changes again.
comp(delta) should probably stay largish, and comp(permoveleeway) is used to gauge time overuns for time-per-move games.

Lots of corner cases to consider.

Code: Select all

set comp(delta) 2000; # 2 seconds is the time
set comp(permoveleeway) 1.75 ;# 175% is the max allowed

(Permanent thinking combined with start from position seems broke too).

[hgm]

Yeah - that gremlin had already been fixed.

I'm going to make the move time-out feature automatic.... (and for today it is disabled).

But how much lee-way should i give an engine in time-per-move games and time-per-game ? I'm thinking

per-game: Time remaining for game + 2 seconds
per-move: Time remaining for move + 2 seconds (which is quite generous i think).

Lee-way?

Engines should get no lee-way whatsoever. An ICS would not give them any lee-way... When the GUI says: think 10000 msec, and it only gets a reply after 10001 msec, it is curtains!

Giving engines leeway in local games will only lead to authors producing engines (tested locally) that will lose on time when playing on ICS.

If you want you can test GUI timing with my timing kit: just play the engines in there against itself, and make a log of the engine communiation. The 0.1msec accurate time stamps printed by the engines will tell you the GUI lag.

[stevenaaus]

I've been trying a few other engines. My list now reads
{Stockfish 2.2} Critter Robbo Ivanhoe {Strelka 5} Crafty Shredder {Komodo 2.03} Komodo {Stockfish 2.1} {Stockfish (skill 5)} {Toga 131} Glaurung22 Glaurung Phalanx Zappa Scidlet Umko-1.2 Stockfish {Gnu Chess} {Gnu Chess 6} {Arasan 11.7} {Arasan 13.4} {Arasan 14.1} Chenard Spike Sloppy Homer Sjeng Igorrit Gaviota DeepSaros2 {Red Queen} Scorpio {Phalanx (SCID)} Marvin {Gnu Chess (xboard)} Gully {Ivanhoe prev (r47)} Phalanx-4.5 Phalanx-ja OliThink-5.3.2 FairyMax Zeta Zct {Stockfish dev} Faile TJChess {GreKo 9} Simon DoubleCheck EXChess

I found EXChess stopped working if the increment was ".1" instead of "0.1".

I wonder how many engines are affected by this sort of formatting issue ? Anyway - i've made a few time values force a leading 0 for decimal values.

Engines should get no lee-way whatsoever. An ICS would not give them any lee-way... When the GUI says: think 10000 msec, and it only gets a reply after 10001 msec, it is curtains!

The leeway is only for time-per-move games. Forfeiting of games would be very common otherwise... This time mechanism isn't very useful anyway.

[JuLieN]

Steven, are you planing to support Retina display in ScidVsMac? Right now its display looks a bit blocky on the new MacBook Pro.