syzygy wrote:Zenmastur wrote: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.
Obviously not.
The non-clipped part is correct. The clipped part is clipped, so you obviously don't see it. Does not make the clipped part incorrect.
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.
1. That the PV got clipped is NOT an indication that the PV is going to change in the future.
2. The PV IS going to change in the future.
1.) Is your claim. My claim, which is based solely on what I have witnessed it do time and time again, is that when it starts clipping the PV it's going to change.
2.) "The PV IS going to change in the future." is flat out wrong. The trivial case is when only one line of play leads to mate and all other lines lose. Once it finds this line of play it will never leave it unless there is a bug. There are, of course, a huge number of other possibilities which lead to the same behavior by the engine. I'm not going to waste a bunch of time trying to list all possibilities, one only needs to engage one's brain to envision what the other possibilities are. e.g. huge material advantage vice huge material loss etc.
syzygy wrote: Since they are very likely to change it would be foolish to rely on them. Therefore the PV is unreliable.
Sure...
Rely on them for what?
To make your next move among other things.
syzygy wrote: You have to realise that the value of terminal node of the (non-clipped) PV is based on a call to eval() which is incredibly unreliable.
I'm well aware that eval() is unreliable. If it were reliable there wouldn't be any need to conduct an extensive search. You could simply produce all legal moves, make each one, call eval(), and select the one with the best score. Since we all know that this algorithm doesn't work well, we all know that eval() is unreliable even if we haven't thought about it explicitly.
syzygy wrote: 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.
With SF5? I kind of doubt it.
Why do you doubt it?
Do you believe that SF5 is perfect?
syzygy wrote: 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).
Such things happen. Search is a complicated thing. If you know the perfect solution, by all means contribute to SF development.
I don't have the "perfect" solution. I don't even have "a" solution. What I do have is a few leads.
I'm still considering if I should embark on another chess programming venture. I have lots of ideas that I didn't get to try out the last time I did this. My problem is this, my health is not very good. I do plan to do something, I just haven't determined what that is yet. I would prefer something that I have a reasonable chance of completing. So for the time being, open ended projects are off the table for me.
syzygy wrote: 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!
Of course I am simplifying. It seems I got the point across, so it worked.
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.
It is only a problem if you want it to be a problem. It is inherent in how alpha-beta search works.
There is nothing inherent in the alpha-beta process that prescribes that each ply deeper into the search must be searched to a depth one ply less than the last. i.e. like this:
Example 1:
9-8-7-6-5-4-3-2-1
There is no reason that something like this couldn't be done:
Example 2:
9-8-7-6-5-5-5-4-3-2-1
or this
Example 3:
9-8-7-6-5-4-3-3-3-3-3-2-1
There are advantages to the alternatives. One is time usage. e.g. if a 1 ply search requires one unit of time and each addition ply of depth doubles the search time then example 1 requires 256 units of time. Example 2 requires 288 units of time and example three requires 272 units of time. Example 2 gets its search horizon extended by two plies and example 3 gets its search horizon extended 4 plies. Both use considerably less time than an 11-ply search (1024 units of time) or a 13-ply search (4096 units of time). Neither is as good as their more traditional counter parts of the same length but they are much better than a straight 9-ply search.
syzygy wrote:Zenmastur wrote: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?
Yes, compiles from April have this problem. They don't always clip where they should. It is fixed in SF5.
This is not a compile from April, the date is Sept. 4 2014. I downloaded it on Sept. 12. Since Sept 12, it's the only version of stockfish I have used.
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.