new PolyGlot

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 15 April 2004 13:17:50:


There should be a new PolyGlot available on Dann's FTP site, but I can't access it at the moment (I could until last week).
It is very important that this version is tested because it has among other things the new code for "crippled pondering", which is much better than the not-working-at-all pondering that Leo insists on using despite my warnings ...
The mysterious "unloading problem" is still mysterious, and I have little hope to find out what it is before the first official release.
So, from now on, I would like users to consider PolyGlot as in beta-testing phase (not development anymore). Note that this only applies to the latest version which might actually not be available (Dann did not tell me).
And, don't ask me for an exe because only Dann has it!!!
Fabien.

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 15 April 2004 15:26:09:
Als Antwort auf:/In reply to: new PolyGlot geschrieben von:/posted by: Fabien Letouzey at 15 April 2004 13:17:50:

There should be a new PolyGlot available on Dann's FTP site, but I can't access it at the moment (I could until last week).
It is very important that this version is tested because it has among other things the new code for "crippled pondering", which is much better than the not-working-at-all pondering that Leo insists on using despite my warnings ...

Not working-at-all pondering is also a problem of movei for similiar reasons.
In the case of movei it can cause losses on time in less than 1/100 of the cases based on my experience.
Movei practically use the correct remaining time when it needs to decide if to do another iteration but it is using wrong remaining time when it needs to stop in the middle of the iteration.
In most cases it does not stop at the middle of the iteration and even if it stops in the middle of the iteration movei has a rule never to use more than half of the remaining time so even using the previous remaining time usually does not cause losing on time.
Uri

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 15 April 2004 15:35:51:
Als Antwort auf:/In reply to: Re: new PolyGlot geschrieben von:/posted by: Uri Blass at 15 April 2004 15:26:09:

There should be a new PolyGlot available on Dann's FTP site, but I can't access it at the moment (I could until last week).
It is very important that this version is tested because it has among other things the new code for "crippled pondering", which is much better than the not-working-at-all pondering that Leo insists on using despite my warnings ...

Not working-at-all pondering is also a problem of movei for similiar reasons.
In the case of movei it can cause losses on time in less than 1/100 of the cases based on my experience.
Movei practically use the correct remaining time when it needs to decide if to do another iteration but it is using wrong remaining time when it needs to stop in the middle of the iteration.
In most cases it does not stop at the middle of the iteration and even if it stops in the middle of the iteration movei has a rule never to use more than half of the remaining time so even using the previous remaining time usually does not cause losing on time.
Uri

Does the "wrong remaining time" come straight from the xboard protocol?
That is, did you expect clocks to be updated after each half move (which would certainly help, but might break some really old engines)?
Fabien.

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 15 April 2004 16:17:52:
Als Antwort auf:/In reply to: Re: new PolyGlot geschrieben von:/posted by: Fabien Letouzey at 15 April 2004 15:35:51:

There should be a new PolyGlot available on Dann's FTP site, but I can't access it at the moment (I could until last week).
It is very important that this version is tested because it has among other things the new code for "crippled pondering", which is much better than the not-working-at-all pondering that Leo insists on using despite my warnings ...

Not working-at-all pondering is also a problem of movei for similiar reasons.
In the case of movei it can cause losses on time in less than 1/100 of the cases based on my experience.
Movei practically use the correct remaining time when it needs to decide if to do another iteration but it is using wrong remaining time when it needs to stop in the middle of the iteration.
In most cases it does not stop at the middle of the iteration and even if it stops in the middle of the iteration movei has a rule never to use more than half of the remaining time so even using the previous remaining time usually does not cause losing on time.
Uri

Does the "wrong remaining time" come straight from the xboard protocol?
That is, did you expect clocks to be updated after each half move (which would certainly help, but might break some really old engines)?
Fabien.

I did not expect winboard to send the remaining time after every half move and the bug is simply a result of not thinking about the problem.
I mainly test with ponder off and in this case movei has the correct remaining time when it starts to calculate.
The situation is different with ponder on and I simply did not think about it when I implemented pondering.

Winboard send the time command before sending the opponent move.
I updated max_time that is half of the remaining time when I got the time command but I did not update another related varaible stop_time that is updated
only when movei starts to calculate(after getting the expected move it does not need to start to calculate)
The solution was simply to delete stop_time and use start_time+max_time instead it and this soplution is implemented in my latest version but not in the public version.
Getting the time command immediately every half ply could not help because movei starts to ponder immediately after making a move and check for winboard commands only during the search so in that case movei may still have the wrong stop_time that is updated only in the beginning of the search.
Uri

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 15 April 2004 19:54:29:
Als Antwort auf:/In reply to: new PolyGlot geschrieben von:/posted by: Fabien Letouzey at 15 April 2004 13:17:50:

There should be a new PolyGlot available on Dann's FTP site, but I can't access it at the moment (I could until last week).

That's it, I can now see it.
Happy testing
Fabien.

[Harald Luessen]

Geschrieben von:/Posted by: Harald Luessen at 15 April 2004 23:09:04:
Als Antwort auf:/In reply to: Re: new PolyGlot geschrieben von:/posted by: Uri Blass at 15 April 2004 16:17:52:

There should be a new PolyGlot available on Dann's FTP site, but I can't access it at the moment (I could until last week).
It is very important that this version is tested because it has among other things the new code for "crippled pondering", which is much better than the not-working-at-all pondering that Leo insists on using despite my warnings ...

Not working-at-all pondering is also a problem of movei for similiar reasons.
In the case of movei it can cause losses on time in less than 1/100 of the cases based on my experience.
Movei practically use the correct remaining time when it needs to decide if to do another iteration but it is using wrong remaining time when it needs to stop in the middle of the iteration.
In most cases it does not stop at the middle of the iteration and even if it stops in the middle of the iteration movei has a rule never to use more than half of the remaining time so even using the previous remaining time usually does not cause losing on time.
Uri

Does the "wrong remaining time" come straight from the xboard protocol?
That is, did you expect clocks to be updated after each half move (which would certainly help, but might break some really old engines)?
Fabien.

I did not expect winboard to send the remaining time after every half move and the bug is simply a result of not thinking about the problem.
I mainly test with ponder off and in this case movei has the correct remaining time when it starts to calculate.
The situation is different with ponder on and I simply did not think about it when I implemented pondering.

Winboard send the time command before sending the opponent move.
I updated max_time that is half of the remaining time when I got the time command but I did not update another related varaible stop_time that is updated
only when movei starts to calculate(after getting the expected move it does not need to start to calculate)
The solution was simply to delete stop_time and use start_time+max_time instead it and this soplution is implemented in my latest version but not in the public version.
Getting the time command immediately every half ply could not help because movei starts to ponder immediately after making a move and check for winboard commands only during the search so in that case movei may still have the wrong stop_time that is updated only in the beginning of the search.
Uri

I think you have been discussing this for some days now
and I am sorry I missed it because I had similar problems
myself. Elephant lost on time while pondering. My solution
was: stop pondering when winboard sends 'time' (and not
the usermove) and then just wait for the usermove (and
while doing this accept the 'otim' command). There is a
new state pondering_done recognized in the main loop.
When winboard sends the usermove I change the state back
to ponder_on and start thinking my own move with the time
calculated based on the 'time' command. Up to now there
is no correction with the waiting time but it already works.
I have increased some time safety margins too. It seems the
empty wait for winboard input loop reacts faster than the
every few thousand node lookup in the search.
Harald

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 15 April 2004 23:47:15:
Als Antwort auf:/In reply to: Re: new PolyGlot geschrieben von:/posted by: Harald Luessen at 15 April 2004 23:09:04:

There should be a new PolyGlot available on Dann's FTP site, but I can't access it at the moment (I could until last week).
It is very important that this version is tested because it has among other things the new code for "crippled pondering", which is much better than the not-working-at-all pondering that Leo insists on using despite my warnings ...

Not working-at-all pondering is also a problem of movei for similiar reasons.
In the case of movei it can cause losses on time in less than 1/100 of the cases based on my experience.
Movei practically use the correct remaining time when it needs to decide if to do another iteration but it is using wrong remaining time when it needs to stop in the middle of the iteration.
In most cases it does not stop at the middle of the iteration and even if it stops in the middle of the iteration movei has a rule never to use more than half of the remaining time so even using the previous remaining time usually does not cause losing on time.
Uri

Does the "wrong remaining time" come straight from the xboard protocol?
That is, did you expect clocks to be updated after each half move (which would certainly help, but might break some really old engines)?
Fabien.

I did not expect winboard to send the remaining time after every half move and the bug is simply a result of not thinking about the problem.
I mainly test with ponder off and in this case movei has the correct remaining time when it starts to calculate.
The situation is different with ponder on and I simply did not think about it when I implemented pondering.

Winboard send the time command before sending the opponent move.
I updated max_time that is half of the remaining time when I got the time command but I did not update another related varaible stop_time that is updated
only when movei starts to calculate(after getting the expected move it does not need to start to calculate)
The solution was simply to delete stop_time and use start_time+max_time instead it and this soplution is implemented in my latest version but not in the public version.
Getting the time command immediately every half ply could not help because movei starts to ponder immediately after making a move and check for winboard commands only during the search so in that case movei may still have the wrong stop_time that is updated only in the beginning of the search.
Uri

I think you have been discussing this for some days now
and I am sorry I missed it because I had similar problems
myself. Elephant lost on time while pondering. My solution
was: stop pondering when winboard sends 'time' (and not
the usermove) and then just wait for the usermove (and
while doing this accept the 'otim' command). There is a
new state pondering_done recognized in the main loop.
When winboard sends the usermove I change the state back
to ponder_on and start thinking my own move with the time
calculated based on the 'time' command. Up to now there
is no correction with the waiting time but it already works.
I have increased some time safety margins too. It seems the
empty wait for winboard input loop reacts faster than the
every few thousand node lookup in the search.
Harald

Correct.


This was not my problem because I always stop pondering after getting the time command and wairted for otime command and the user move.
the relevant code that movei does when it get the time command during pondering
is at the bottom of this post.
My problem was that stop_time was not updated in the time command(max_time was updated) and I solved it by deleting stop_time and replacing every stop_time by start_time+max_time.
My code is still not perfect because I have some varaible ponder_enough to tell movei that it already used enough time during pondering so movei will play in 0 seconds in case of getting the expected move when ponder_enough is 1.
ponder_enough is 0 when movei starts to ponder and it is changed to 1 if movei
finish iteration with enough time(and can be changed again to 0 in case of fail low or fail high that was not solved and may be wrong fail high).
Now deciding if movei finished an iteration with enough time is based on the wrong time but this problem cannot cause movei to lose on time.


if(!strcmp(command, "time"))
{
time_command();
fgets(buffer, sizeof buffer, stdin);
sscanf(buffer, "%s", command);
if (!strcmp(command,"otim"))
{
fgets(buffer, sizeof buffer, stdin);
}

/*you now have the move in buffer
so check if it is the expected move*/
analyze=PLAY_MODE;
/*continue_to_ponder decides if to stop
pondering and take back all the moves and continue a
new search or not to do it*/
continue_to_ponder();
break;

[Harald Luessen]

Geschrieben von:/Posted by: Harald Luessen at 16 April 2004 00:49:42:
Als Antwort auf:/In reply to: Re: new PolyGlot geschrieben von:/posted by: Uri Blass at 15 April 2004 23:47:15:

I think you have been discussing this for some days now
and I am sorry I missed it because I had similar problems
myself. Elephant lost on time while pondering. My solution
was: stop pondering when winboard sends 'time' (and not
the usermove) and then just wait for the usermove (and
while doing this accept the 'otim' command). There is a
new state pondering_done recognized in the main loop.

Correct.


This was not my problem because I always stop pondering after getting the time command and wairted for otime command and the user move.

Hm. I answered a question you had not asked. And because I am
doing another (weaker?) kind of pondering our engines are too
different and cannot have the same solutions.
Do you know whether winboard sends the commands time, otim and
the usermove in maximal speed or is there a time delay between
them?
Another question: Is it possible that winboard needs some
extra time with the last move in a time control M moves in N
seconds. Perhaps it is testing if a flag fell. If I remember
correctly I observed a bigger difference between my time
control and winboard's time at the last move. But I am not
sure and I see no reason for such a behavior on fast PCs.
Exaggerated:
... 50000 msec for 10 moves ...
Winboard says "time 10000 msec for 2 moves".
I tell my engine "use 4000 msec for one move". (defensive)
Winboard says "time 5000 msec for 1 move". (where are 1000 msec?)
I tell my engine "use 3000 msec for one move". (very defensive at last move)
Now I successfully pass the time control. (with +100 msec,
Winboard says "time 50100 msec for 10 moves". (where are 1900 msec?)
...
Perhaps I still have a hidden problem.
Harald

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 16 April 2004 01:23:11:
Als Antwort auf:/In reply to: Re: new PolyGlot geschrieben von:/posted by: Harald Luessen at 16 April 2004 00:49:42:

I think you have been discussing this for some days now
and I am sorry I missed it because I had similar problems
myself. Elephant lost on time while pondering. My solution
was: stop pondering when winboard sends 'time' (and not
the usermove) and then just wait for the usermove (and
while doing this accept the 'otim' command). There is a
new state pondering_done recognized in the main loop.

Correct.


This was not my problem because I always stop pondering after getting the time command and wairted for otime command and the user move.

Hm. I answered a question you had not asked. And because I am
doing another (weaker?) kind of pondering our engines are too
different and cannot have the same solutions.
Do you know whether winboard sends the commands time, otim and
the usermove in maximal speed or is there a time delay between
them?
Another question: Is it possible that winboard needs some
extra time with the last move in a time control M moves in N
seconds. Perhaps it is testing if a flag fell.
correctly I observed a bigger difference between my time
control and winboard's time at the last move. But I am not
sure and I see no reason for such a behavior on fast PCs.
Exaggerated:
... 50000 msec for 10 moves ...
Winboard says "time 10000 msec for 2 moves".
I tell my engine "use 4000 msec for one move". (defensive)
Winboard says "time 5000 msec for 1 move". (where are 1000 msec?)
I tell my engine "use 3000 msec for one move". (very defensive at last move)
Now I successfully pass the time control. (with +100 msec,
Winboard says "time 50100 msec for 10 moves". (where are 1900 msec?)
...
Perhaps I still have a hidden problem.
Harald

I do not know.
I think that if it needs time then the time is very small so I do not care about it(I always plan to take safety margin not because of winboard but because movei check for winboard commands during pondering only every 16384 nodes so it is possible that movei need time to get the time command and it is not the fault of winboard that when movei read time 1000 the time is really smaller).
It may be better not to do it every 16384 nodes but to use the time control but
I do not care about very fast games with pondering and the problem of losing on time in games of 1 minute/40 moves was not because of not getting the time command fast enough but because of the bug that I mentioned.
Uri


If I remember

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 16 April 2004 12:08:21:
Als Antwort auf:/In reply to: Re: new PolyGlot geschrieben von:/posted by: Harald Luessen at 15 April 2004 23:09:04:

I think you have been discussing this for some days now
and I am sorry I missed it because I had similar problems
myself. Elephant lost on time while pondering. My solution
was: stop pondering when winboard sends 'time' (and not
the usermove) and then just wait for the usermove (and
while doing this accept the 'otim' command). There is a
new state pondering_done recognized in the main loop.
When winboard sends the usermove I change the state back
to ponder_on and start thinking my own move with the time
calculated based on the 'time' command. Up to now there
is no correction with the waiting time but it already works.
I have increased some time safety margins too. It seems the
empty wait for winboard input loop reacts faster than the
every few thousand node lookup in the search.
Harald

I believe a correct implementation in an xboard engine is as follows:
1) don't allocate time when you start pondering (you don't have correct clock info at that time); so just search in "infinite" mode
2) don't modify your pondering when you receive time or otim, a user move will arrive soon
3) when you receive the usermove and it matches the move you were pondering on, then allocate the search time (without interrupting the search); that is, calculate the values for your internal max_time variable etc ... and leave "infinite" mode.
Unfortunately I can't do this in PolyGlot because UCI does not allow time to be "allocated" *during* pondering (it must be done when starting it, and WinBoard won't send me the needed information).
Fabien.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 16 April 2004 12:09:56:
Als Antwort auf:/In reply to: Re: pondering with WinBoard geschrieben von:/posted by: Fabien Letouzey at 16 April 2004 12:08:21:

2) don't modify your pondering when you receive time or otim, a user move will arrive soon

^^^
Of course you need to update your global time/otim variables everytime you receive those, but my point is that the values will only be used later.
Fabien.

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 16 April 2004 13:57:53:
Als Antwort auf:/In reply to: Re: pondering with WinBoard geschrieben von:/posted by: Fabien Letouzey at 16 April 2004 12:08:21:

I think you have been discussing this for some days now
and I am sorry I missed it because I had similar problems
myself. Elephant lost on time while pondering. My solution
was: stop pondering when winboard sends 'time' (and not
the usermove) and then just wait for the usermove (and
while doing this accept the 'otim' command). There is a
new state pondering_done recognized in the main loop.
When winboard sends the usermove I change the state back
to ponder_on and start thinking my own move with the time
calculated based on the 'time' command. Up to now there
is no correction with the waiting time but it already works.
I have increased some time safety margins too. It seems the
empty wait for winboard input loop reacts faster than the
every few thousand node lookup in the search.
Harald

I believe a correct implementation in an xboard engine is as follows:
1) don't allocate time when you start pondering (you don't have correct clock info at that time); so just search in "infinite" mode
2) don't modify your pondering when you receive time or otim, a user move will arrive soon
3) when you receive the usermove and it matches the move you were pondering on, then allocate the search time (without interrupting the search); that is, calculate the values for your internal max_time variable etc ... and leave "infinite" mode.
Unfortunately I can't do this in PolyGlot because UCI does not allow time to be "allocated" *during* pondering (it must be done when starting it, and WinBoard won't send me the needed information).
Fabien.

I am practically in infinite mode before getting the opponent move.
The problem is that when I get the expected move I need to update not only the internal max_time but also the varaible ponder_enough that tells me if to play move immediately when I get the ponder move.
Today I do not do it and it can
cause a problem when movei may decide to play immediately based on wrong information(for example if it ponders at move 41 and the time control is 2 hours/40 moves and the last time command that it got from winboard is 3 minutes then it may assume that it has only 3 minutes for moves 41-80 so it may assume after few seconds that it pondered enough and play immediately when getting the expected move when it is not justified).
I plan to fix the problem.

Maybe polyglot can claulcate the relevant information based on the time that the engine used when it played the last move and the time control.
You can always assume slightly less time then the calculated time in order to be careful because you cannot trust the calculated time to be the same as the time that winboard is going to send.
Uri

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 16 April 2004 14:03:26:
Als Antwort auf:/In reply to: Re: pondering with WinBoard geschrieben von:/posted by: Fabien Letouzey at 16 April 2004 12:09:56:

2) don't modify your pondering when you receive time or otim, a user move will arrive soon

^^^
Of course you need to update your global time/otim variables everytime you receive those, but my point is that the values will only be used later.
Fabien.

When I get the time command I wait passively for a move because I assume that a move is going to come immediately.
If there is an interface that does not give a move immediately after the time command then it is a bad behaviour of the interface.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 16 April 2004 14:11:34:
Als Antwort auf:/In reply to: Re: pondering with WinBoard geschrieben von:/posted by: Uri Blass at 16 April 2004 13:57:53:

Maybe polyglot can claulcate the relevant information based on the time that the engine used when it played the last move and the time control.
You can always assume slightly less time then the calculated time in order to be careful because you cannot trust the calculated time to be the same as the time that winboard is going to send.

I thought about it, but it fails if the last move was searched in pondering mode.
The engine will report search time, not clock time.
Fabien.

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 16 April 2004 14:13:28:
Als Antwort auf:/In reply to: Re: pondering with WinBoard geschrieben von:/posted by: Uri Blass at 16 April 2004 14:03:26:

2) don't modify your pondering when you receive time or otim, a user move will arrive soon

^^^
Of course you need to update your global time/otim variables everytime you receive those, but my point is that the values will only be used later.
Fabien.

When I get the time command I wait passively for a move because I assume that a move is going to come immediately.
If there is an interface that does not give a move immediately after the time command then it is a bad behaviour of the interface.

Note that I am talking about behaviour of the interface with only winboard engines
The behaviour with UCI engines should be different because I understand that UCI engines expect to get the time command before they begin to ponder(only winboard engines do not have ponder command so there is no way to tell them to get the time command after they play but before they start to ponder).
Uri

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 16 April 2004 14:15:39:
Als Antwort auf:/In reply to: Re: pondering with WinBoard geschrieben von:/posted by: Uri Blass at 16 April 2004 14:03:26:

2) don't modify your pondering when you receive time or otim, a user move will arrive soon

^^^
Of course you need to update your global time/otim variables everytime you receive those, but my point is that the values will only be used later.
Fabien.

When I get the time command I wait passively for a move because I assume that a move is going to come immediately.
If there is an interface that does not give a move immediately after the time command then it is a bad behaviour of the interface.

I agree, but what's the point?
- when you receive time/otim, just update global variables.
- when you receive opponent move or "go", you know the remaining time
Fabien.

[Uri Blass]

Geschrieben von:/Posted by: Uri Blass at 16 April 2004 14:19:33:
Als Antwort auf:/In reply to: Re: pondering with WinBoard geschrieben von:/posted by: Fabien Letouzey at 16 April 2004 14:11:34:

Maybe polyglot can claulcate the relevant information based on the time that the engine used when it played the last move and the time control.
You can always assume slightly less time then the calculated time in order to be careful because you cannot trust the calculated time to be the same as the time that winboard is going to send.

I thought about it, but it fails if the last move was searched in pondering mode.
The engine will report search time, not clock time.
Fabien.

I think that in this case the search time for UCI engines is the difference between clock time of both engines(winboard engines may decide to ponder on more than one move so I can claim nothing general about them).
Uri

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 16 April 2004 14:59:08:
Als Antwort auf:/In reply to: Re: pondering with WinBoard geschrieben von:/posted by: Uri Blass at 16 April 2004 13:57:53:

Unfortunately I can't do this in PolyGlot because UCI does not allow time to be "allocated" *during* pondering (it must be done when starting it, and WinBoard won't send me the needed information).

Maybe polyglot can claulcate the relevant information based on the time that the engine used when it played the last move and the time control.
You can always assume slightly less time then the calculated time in order to be careful because you cannot trust the calculated time to be the same as the time that winboard is going to send.

I assumed you meant trusting time as reported by the engines. This can't be done of course, as they would count search done during the opponent time as well.
Maybe instead you meant that PolyGlot should measure the time itself. Of course, this is the only solution I can think of. It is just a very bad solution from a software-design point of view, as it duplicates work WinBoard is already doing (and with less precision anyway, as you point out).
I will do it at some point though, I'm just very disappointed that there is no clean solution for this problem (again only in the case of a UCI adapter, it can be made clean in an xboard engine).
In any case, finding out the problem is 99% of the work! I am sure some other programmers have the same problem because they are unaware of it.
Fabien.