UCI pondering done right

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
hgm
Posts: 23014
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI pondering done right

Post by hgm » Tue Dec 18, 2018 4:44 pm

Ras wrote:
Tue Dec 18, 2018 3:49 pm
The go with the times is exactly right with UCI because you just allocate the normal move time and abort search when either stop arrives, or both ponderhit AND time elapse. Besides, it's actually a big plus with UCI that it doesn't get "fixed" all the time.
How can it be 'exactly right' to require info that is not yet known? :shock:

User avatar
hgm
Posts: 23014
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI pondering done right

Post by hgm » Tue Dec 18, 2018 4:45 pm

Michel wrote:
Tue Dec 18, 2018 4:43 pm
It's not strictly stateless but the state is short lived.
The setting of the Ponder or UCI_Analyze option is not short-lived.

Ras
Posts: 1087
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI pondering done right

Post by Ras » Tue Dec 18, 2018 9:12 pm

hgm wrote:
Tue Dec 18, 2018 4:44 pm
How can it be 'exactly right' to require info that is not yet known?
It doesn't require info that isn't known yet. Everything is there. If you absolutely want to take opponent's time into consideration, here is the formula: current_opp_time = opp_time_from_go - your_time_until_ponderhit. Big deal. However, I wouldn't recommend that anyway because it will fall flat on games with asymmetric thinking time (i.e. time handicap).
Rasmus Althoff
https://www.ct800.net

User avatar
hgm
Posts: 23014
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI pondering done right

Post by hgm » Tue Dec 18, 2018 9:23 pm

So you propose the engine should work around the flaw in the protocol, and then point out that it cannot reliably do that.

And this should make the protocol then 'exactly right'?

If you are not supposed to use the opponent time, why demand it is sent with the 'go' command at all? The whole point of sending those times is that the engine does not have to measure them by itself. You might as well require an extra parameter 'easterdate' on every 'go' command. I suppose that would have made the protocol 'exactly righter' still...

Ras
Posts: 1087
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI pondering done right

Post by Ras » Tue Dec 18, 2018 9:44 pm

hgm wrote:
Tue Dec 18, 2018 9:23 pm
So you propose the engine should work around the flaw in the protocol
There is no flaw in the protocol here that needs to be "fixed".
If you are not supposed to use the opponent time, why demand it is sent with the 'go' command at all?
One of the UCI design goals was to strive for uniform handling, and the GUI just always puts both sides' time data into the go command. The engine is not obliged to evaluate irrelevant data. Since stdin/out is not paid per byte, it doesn't really make sense to "optimise" and introduce more if/else code paths that would just increase the probability of bugs.
Rasmus Althoff
https://www.ct800.net

User avatar
hgm
Posts: 23014
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI pondering done right

Post by hgm » Wed Dec 19, 2018 4:33 pm

So in your judgement, requiring data to be sent at a time it is not available is not a flaw.

I am afraid that says more about your judgement than about the protocol, though... But it makes it pointless to discuss this any further.

elcabesa
Posts: 780
Joined: Sun May 23, 2010 11:32 am
Contact:

Re: UCI pondering done right

Post by elcabesa » Wed Dec 19, 2018 4:43 pm

hgm wrote:
Wed Dec 19, 2018 4:33 pm
So in your judgement, requiring data to be sent at a time it is not available is not a flaw.

I am afraid that says more about your judgement than about the protocol, though... But it makes it pointless to discuss this any further.
YOU are a moderator of those forum, please act like a moderator and stop attacking everyone who don't think like you.

User avatar
hgm
Posts: 23014
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: UCI pondering done right

Post by hgm » Wed Dec 19, 2018 4:55 pm

Attack? Since when is questioning someone's judgement an attack? I did not even mention what it says about his judgement. If you think my above statement implies that he is an idiot, (say), then that is 100% your own conclusion... Presumably based on what you think about his judgement yourself.

Or do you agree that it is no flaw for a protocol to require something that is absolutely impossible?

elcabesa
Posts: 780
Joined: Sun May 23, 2010 11:32 am
Contact:

Re: UCI pondering done right

Post by elcabesa » Wed Dec 19, 2018 5:26 pm

I agree that in some places the UCI protocol could have been done better, but I think it's good enough.

what I sometimes don't agree, is that I think that a moderator moderator shall be attentive and always polite with other members. This is my opinion, but English is not my first language and i could be wrong

Ras
Posts: 1087
Joined: Tue Aug 30, 2016 6:19 pm
Contact:

Re: UCI pondering done right

Post by Ras » Wed Dec 19, 2018 7:37 pm

hgm wrote:
Wed Dec 19, 2018 4:33 pm
requiring data to be sent at a time
Please re-read what I wrote on why it's a bad idea to evaluate the opponent's time anyway. The supplied data are not necessary, and that irrelevant data are suppplied is not a problem. And even IF you want to implement that bad idea, you DO have that information anyway.

On top of that, it's astonishing how keen you suddenly are on evaluating the opponent's time. Your source code in kingslayer for "otim" reads as follows:

Code: Select all

if(!strcmp(command, "otim"))    { continue; } // move will follow immediately, wait for it
And here's how you treat "otim" in Fairymax:

Code: Select all

if (!strcmp(command, "otim")) {
    /* opponent's time (not kept, so ignore) */
    continue;
Rasmus Althoff
https://www.ct800.net

Post Reply