zurichess geneva released

[MikeB]

That's how time works in golang. The underlying type, time.Duration, represents number of nanoseconds. See documentation https://golang.org/pkg/time/#Duration

See also this example

http://play.golang.org/p/9bWBQgz-kz

which outputs

5s 5000000000


The fact that `go movetime 5000` takes only a sec is a consequence of poor branching factor estimation.

That is different from most of the engines I ever worked with , if you tell it to take 5 seconds , it takes 5 seconds. Well anyway , it is reporting seconds ( time used) and nps second accurately so there is nothing wrong with how it's gathering or reporting time - so it does not appear to have any specific OS X time reporting defect.

[brtzsnr]

That is different from most of the engines I ever worked with , if you tell it to take 5 seconds , it takes 5 seconds. Well anyway , it is reporting seconds ( time used) and nps second accurately so there is nothing wrong with how it's gathering or reporting time - so it does not appear to have any specific OS X time reporting defect.

The reason of the difference is mostly historic. Early versions didn't stop the search when time was up. The search was stopped only between iterations so for each new depth zurichess estimated how much it would take and decided whether to deepen the search or to stop. That didn't worked very well on a few positions on which search exploded http://www.talkchess.com/forum/viewtopic.php?t=57020.

Now zurichess stops the search when the time is up, but it still uses the same mechanism to decide when not to start the search. I like this strategy because it doesn't waste time on aborted searches.

Also, I haven't given time management enough thought, but occasionally I get 10-15 ELO improvement from it. E.g. in this version if the move predicted (second on pv) matches the opponent's move then the search time is increased a bit.

[Sylwy]

http://www.talkchess.com/forum/viewtopi ... 62&t=50060