bob wrote:
How do you solve the hashing problems this will incur? In your evaluation, P and P' are the same position but reached by different paths. You evaluate them differently and produce different scores. But when hashing, P and P' are identical and one of the scores is, by definition, wrong...
This looks like you are simply adding a random term to the evaluation here and there as a result...
Your criticism makes no sense. Do you use LMR?
If yes, you can store different scores from the same depth, because the underlying searches can have different depths and will end up at different leaf positions. This is ugly, but I think you agree LMR works.
Dann Corbit wrote:I think that sometimes a good positional move will slowly improve over time, whereas a game that is really drawn (for instance) will have a score that hits a fixed number and then stays pegged at that value.
Uri's idea captures not only the value of the score but also the direction of the score.
Sometimes, the "improved" directional score will get over-written with a version that does not have this information. This will result in a small loss of information.
There are many other things that will cause sudden changes in our evaluation of a position. So I think it is in line with many other things that can have the same effect, but for which the estimate that they provide is better than the estimate without the added information.
Suppose (for instance) that a search extension gets triggered and something vile or wonderful is found just over the horizon. This also causes a jump in score. It is also possible for this information to be overwritten. But the better information provided value while it was there.
My theory is that if the duration of the information is long enough to provide enough value to overcome the cost of calculation before being overwritten (on average) then it will result in improved game play.
Of course, things like this will make the engine search less determinstic. Of course, sometimes that is a good thing (so that opponents cannot set simple traps for your engine from what it has learned before because it is moody) and sometimes it is a bad thing (trying to debug a problem).
Just a theory, but it makes sense to me.
The problem is, in quite a few positions, this is not "information lost in just a few positions". Take fine 70. You get _way_ more from the hash than from the evaluation function.
correct but still movei is going to get it correct quickly.
The point is that the hash is going to save a lot of searches when
the hash is not dependent on the path.
I believe that even if you add a small random noise to the evaluation(not more than 0.3 pawns) and do not change your hash code you are going to solve fine70 quickly.
I do not claim that adding a small random noise is a good idea to improve the evaluation but only that it is not going to change much in fine70.
The point is that you are consistent in your cutoff because you do not evaluate when you have a cutoff so if you get a cutoff based on the hash then you continue to get the same cutoff later at different paths(unless you are going to search to a bigger depth).
repetition is always evaluated as 0.00 and this is not going to be hash dependent.
Uri
Suppose your _first_ search hits the path that is not "optimal" with respect to the path scoring and your add in zero. Now each time you search a different path that leads to this position, you get the zero bonus, even though the evaluation would add the bonus in, if it were only given the chance. But the hash entry caused the search to terminate instantly, based on the old (wrong) score.
bob wrote:
How do you solve the hashing problems this will incur? In your evaluation, P and P' are the same position but reached by different paths. You evaluate them differently and produce different scores. But when hashing, P and P' are identical and one of the scores is, by definition, wrong...
This looks like you are simply adding a random term to the evaluation here and there as a result...
Your criticism makes no sense. Do you use LMR?
If yes, you can store different scores from the same depth, because the underlying searches can have different depths and will end up at different leaf positions. This is ugly, but I think you agree LMR works.
So that's not a valid criticism of this idea.
That is completely unrelated. He is describing computing a path-dependent scoring term, but the hash table can completely hide this, or apply it to all identical positions, whether the path-dependent feature actually exists or not.
can't you solve the hash issue by storing 2 numbers in the hash, the path-independent score, and the path-dependent score? Then when a node accesses the hash, it can take the path-independent score, add its own path, and then compare?
Gian-Carlo Pascutto wrote:
Your criticism makes no sense. Do you use LMR?
If yes, you can store different scores from the same depth, because the underlying searches can have different depths and will end up at different leaf positions. This is ugly, but I think you agree LMR works.
So that's not a valid criticism of this idea.
That is completely unrelated.
It certainly is. From the point of view of a (say) 5 ply search, both LMR and this idea can give different scores depending on the path and store them in the hash, causing further lookups that would have triggered different searches or evals to get values different than they would have otherwise.
Does this mean those ideas don't work? No.
Imagine that instead of doing Uri's idea I'm doing 3 ply LMR searches to evaluate a node. Exactly the same effect. Different path gives different score, but all is stored in the hash anyway.
He is describing computing a path-dependent scoring term, but the hash table can completely hide this, or apply it to all identical positions, whether the path-dependent feature actually exists or not.
Yes, that's perfectly true. Does it matter? Apparently not.
BubbaTough wrote:can't you solve the hash issue by storing 2 numbers in the hash, the path-independent score, and the path-dependent score? Then when a node accesses the hash, it can take the path-independent score, add its own path, and then compare?
-Sam
I don't know about you but I like to hash my search results, not just my evaluation results...
BubbaTough wrote:can't you solve the hash issue by storing 2 numbers in the hash, the path-independent score, and the path-dependent score? Then when a node accesses the hash, it can take the path-independent score, add its own path, and then compare?
-Sam
Using that scheme, why would you store the path dependent score? It doesn't look like you would ever use it again.
BubbaTough wrote:can't you solve the hash issue by storing 2 numbers in the hash, the path-independent score, and the path-dependent score? Then when a node accesses the hash, it can take the path-independent score, add its own path, and then compare?
-Sam
Using that scheme, why would you store the path dependent score? It doesn't look like you would ever use it again.
Good point. When I wrote this I was thinking at any point to get the path adjusted score at any point, you just need the path independent score, and then add your own path. Now that I think about it a little more I don't think that is correct. Nevermind.
Hi, after seeing the results in searches to fixed depth I didn't want to test it very much, but at least I played some games. This is not a probe but seeing this and seeing that in fixed search depth the node count is increased too much(37%), it discourages me.
