Chess Tempo

Username:
Password:
/ Register

User Details

Username:
Blitz Rating:
Standard Rating:
Logout
January 08, 2009, 06:14:31 am *
Welcome, Guest. Please login or register.
News: SMF - Just Installed!
 
Pages: [1]
Print
Author Topic: 39328 -- alt is dup of main line  (Read 338 times)
revenant
Full Member
***
Posts: 210


View Profile
« on: November 14, 2008, 04:01:43 am »

(39328)

In the variations sidebar, one of the alts listed at move 3 is a duplicate of the main line move.
Logged
richard
Administrator
Hero Member
*****
Posts: 1086



View Profile
« Reply #1 on: November 14, 2008, 07:15:37 am »

I believe I have code in the generator now which filters out these positions, but I haven't done a full verification run since adding it (it is also possible I only filter out alternatives that have the same move as other alternatives and not alternatives with the same move as the best move, I'll have to check).  I don't completely understand why toga does this. I see it when running in multipv mode in a UI sometimes. It appears that the engine is in some intermediate state where it hasn't updated the multipv lines. If you look carefully you'll see the lines are not exactly the same there, only the start of the move sequence.  Uri if he is reading might be able to shed some light on why an engine would show such a state.

Regards,
Richard.
Logged
cyanfish
Newbie
*
Posts: 17


View Profile
« Reply #2 on: November 15, 2008, 04:29:40 am »

I have a suspicion that this has to do with their being different depths, and the engine output order. When you watch the PV lines change as you get to a reasonable depth, they often change one at a time as that is how the engine generates them.
I am under the impression that during these intermediate states, the output lines are primary sorted by depth and secondary sorted by eval, but if the lines change at all then it won't automatically remove the old one. So if Toga has yet to output all N lines at a given depth, and its top line has changed its full line, there may be duplicates of the first move in later lines.

So my point is that if you somehow wait until the output ply counts are all equal before taking the lines, this may very well eliminate the problem.
Logged
richard
Administrator
Hero Member
*****
Posts: 1086



View Profile
« Reply #3 on: November 15, 2008, 10:09:07 am »

Hi Cyanfish,

Thanks, your description fits what I have seen , so that is probably what is happening. At the moment I wait for a fixed amount of time rather than a fixed depth (depth limiting can have some serious side effects when extension of the line is absolutely required), so waiting for all pvs to get to the same depth is a little tricky.  At the moment I think I'm avoiding problems with duplicate lines caused by this issue, but I haven't run the fix over the entire problem set yet, so there are still some older problems with the issue.

Richard.
Logged
Pages: [1]
Print
Jump to: