syzygy wrote:Zenmastur wrote:I don't know if I agree 100%, but I do know that if your dredging your cache for the PV and the time control is long enough that major portions of the cache are over written before the move is made or analysis stopped, the last PV out put is likely to be trashed. This makes it completely unreliable and is a nightmare as far as time is concerned.
Clipping of the PV in SF does not make the non-clipped part unreliable.
I assume that you are stating that the clipped PV leads to the position that produced the current score.
I'm saying that the fact that it got clipped in the first place is a good indication that the PV is going to change in the near future. Since they are very likely to change it would be foolish to rely on them. Therefore the PV is unreliable.
syzygy wrote: I save the PV's and then use the engine to search each and every move in it to ferret out all the trash moves. I can't ever recall a case where the PV was accurate. I always find errors and the evaluations always change.
Sure, but what do you expect?
I expect a PV that doesn't have a bad/losing move at ply 2 after a 45-60 ply search. I have run across this condition on several occasions.
But this issue is a secondary issue. The reason I began saving the PV's in the first place WAS NOT so I could find errors in them. It was the direct result of having the program complete an iteration in just under 4 minutes and then not being able to complete the next iteration in over a hundred hours of analysis. (100*60/4=1500 times as long). I actually thought Arena had frozen. It hadn't. SF was still calculating but hadn't generated any output for over two days. To get around this problem I appended the PV to the game and began analyzing it. I figured that it would be a long and difficult analysis. It wasn't. It went very rapidly and in less than an hour I had a usable line of play.
Since then I run into these positions all the time, although not quite as extreme as this case. To speed things up when this happens I began appending the PV's and analyzing them as a matter of course. When I started doing this on a regular basis is when I started noticing the rather large number of errors in the PV's. But like I said, this is a secondary issue, although the two could be related. I.E. the inability to find the errors in the PV on it's own could be causing the excessive time usage on an iteration, but I don't know for sure that this is the case.
syzygy wrote:If the root position is searched to depth 40, then the position after 20 half moves was searched only to depth 20. That's just how things work.
Even if you get SF (or any other engine) to return a long PV, putting a lot of trust in the second half of the PV isn't very wise.
You make it sound like the first half of the PV is perfect and everything that is bad in the PV occurs in the second half. I know that's not true and I suspect that you do as well!
The probability of there being an error in the PV at any particular move is a function of its distance from the root position. The exact nature of this function isn't clear to me since, as yet, I haven't kept track of every error and its position in the PV. If I had then I could plot them and or find an equation that mimics their behavior. While this could still be done it would be time consuming. I didn't really think that that level of proof was required to mention it in passing in this forum. This wasn't the reason I started this thread, but it is a problem none the less.
I also know that making each move in the PV the root position in a search has an almost magical ability to make the engine find errors with out extensive searching. i.e. the number of errors found is disproportionate to the time spent finding them if the erroneous move is at ply one in a search.
syzygy wrote:
Note that the OP is complaining about the moves of "perfectly accurate" PVs. (Those output by somewhat recent versions of SF are accurate in so far as they are not clipped.)
Somewhat more recent?
I'll change versions if it fixes the problem. I just don't like changing with every compile and I won't change at all (except for critical fixes) after I start a project with a version because it can waste a huge amount of time. So what you are saying is that the 09042014 compile has this issue and If I get a newer version the PV's will always lead to the node that produced the score displayed even if the PV has been clipped. Is that correct?
The main issue of the program vacillating for long periods of time due to insufficient cache, still appears to be a problem, although I found a temporary work around until I have more time to spend on it.
The last issue:
Stockfish, on occasion, will take disproportionately large amounts of time to complete an iteration as compared to previous iterations.
syzygy wrote: If you walk along this PV while letting the engine search, then obviously the score keeps changing as the engine is searching deeper and deeper. This is what the OP must be talking about in the part I am quoting, unless he is not using SF5 or something more recent.
This IS NOT what the OP is talking about.
Your first statement isn't true. If you almost never do deep searches then you will almost never see a PV that doesn't change even at significant depth. I see them all the time. I've seen PV's that wont change a single move in the PV with large amounts of additional search. i.e. 20 plies deeper. These PV's do exist contrary to what you seem to think. These are not the ones that concern me however.
If you always do shallow searches you should expect the PV to change almost at random even within a single iteration. This means something. It means the program has no clue as to what the best line of play is. When these random changes to the PV stop occurring, it also means something. It means the program "might" have a clue about the position. I prefer the later type myself.
What I don't like is a PV that's 50 or more plies long that has an inaccurate move near the root. Maybe that's all the program is capable of. I don't know. But like I said, my real interest is in why under certain circumstances SF can't get the next iteration done in a reasonable period of time. The natural question that comes to my mind is are these two problems related?
Regards,
Forrest
Only 2 defining forces have ever offered to die for you.....Jesus Christ and the American Soldier. One died for your soul, the other for your freedom.