kinderchocolate wrote:lucasart wrote:mar wrote:The uci script uses go infinite and stop after a timeout, so there are only two possibilities:
- there is a problem with the script itself
- engines don't handle go infinite and/or stop properly
Thanks. That explains everything. DiscoCheck doesn't handle the "stop" command (because I hate writing ugly ifdef's and pateform specific code). However, it handles the "go movetime", so I can modify the script to do that instead.
On the other hand, I don't really care, as I'm really not interested in these tournaments. I was just curious as to what this fingerprint was.
Lucas, any possibility for DiscoCheck supporting infinite analysis and skills level?
OK: the next release will handle the stop command (hence infinite analysis).
As for skill level, you can already limit the strength by using a depth and/or nodes limit. As far as I know there are two ways of limiting ELO:
(i) quick and dirty: each skill level corresponds to a limit in terms of depth and/or nodes (probably a min depth and max nodes is best).
(ii) more proper: start by implementing multi-PV, and choose randomly from the various PVs, with parameters that effectively control the skill level.
Typically what happens is that:
(i) plays very strong positionally, dominates the newbie player, and makes a stupid mistake every now and then (due to low depth) that looses some games. not a very realistic way of simulating a weak player.
(ii) is a more balanced blend, playing moves that are both positionally inferior and tactically (but some blunder margin can avoid really stupid tactics).
But whether you do (i) or (ii), you will never make an engine simulate a weak player in a credible way. That's not how weak players play, and the computer will play random moves that don't follow any plan. A weak player will play with a plan: a stupid one, and sometimes sticking to the plan to stubbornly disregarding important things, but still with some plan.
Best way is to play against real humans on a chess server
Long story short, I may implement (i) or perhaps (ii) but I don't know when. Also there's the problem of calibrating those, so that the ELO value is somewhat realistic (this is a difficult, perhaps it could be tuned based on user feedback, but I don't see any reliable way of doing it).
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.