Draw detection code for closed positions in Crafty 20.0

[Kempelen]

Hi Bob,

About your draw closed positions code in 20.0 version, it happens to me that maybe you can mantein the code without hurting the performance too much with a little trick. Actually, every eval you do, you call this routine to trying to detect this kind of possitions. I thought that there is no need to look for this always. Before starting the root search at iteration 1, you can call a routine that will tell you if the current position has potential to have blocked positions (i.e. if its detects four or more blocked pawns). If it has, you set a flag that will let you to eval with this code, otherwise, you do normal eval. The only hurt-down is a if condition in each eval, which for me maybe is worthy.

The main idea is that a position which "looks" at the root as not closed, it will continue that way in deep searchs.

There could also be variations, i.e, you can, after each iteration, to call the routine I say above to get the flag again, with more criterions, like if the pv has no captures, or pawn moves. What you do, this routine is only called at root very few times, so no much hurt. The flag is what is important to trigger eval code.

Hope you find this interesting to test.

Kind regards and happy Christmas.
Fermin Serrano

[bob]

Hi Bob,

About your draw closed positions code in 20.0 version, it happens to me that maybe you can mantein the code without hurting the performance too much with a little trick. Actually, every eval you do, you call this routine to trying to detect this kind of possitions. I thought that there is no need to look for this always. Before starting the root search at iteration 1, you can call a routine that will tell you if the current position has potential to have blocked positions (i.e. if its detects four or more blocked pawns). If it has, you set a flag that will let you to eval with this code, otherwise, you do normal eval. The only hurt-down is a if condition in each eval, which for me maybe is worthy.

The main idea is that a position which "looks" at the root as not closed, it will continue that way in deep searchs.

There could also be variations, i.e, you can, after each iteration, to call the routine I say above to get the flag again, with more criterions, like if the pv has no captures, or pawn moves. What you do, this routine is only called at root very few times, so no much hurt. The flag is what is important to trigger eval code.

Hope you find this interesting to test.

Kind regards and happy Christmas.
Fermin Serrano

I have been thinking about it. But there is a risk. If you don't ALWAYS do that eval term, you might well defer it until the draw is too close to avoid. For example, locking the 4th pawn in your suggestion might be too late, as the other two pawns will become locked and there is nothing you can do about it...

I am certainly thinking about it...

[Kempelen]

I have been thinking about it. But there is a risk. If you don't ALWAYS do that eval term, you might well defer it until the draw is too close to avoid. For example, locking the 4th pawn in your suggestion might be too late, as the other two pawns will become locked and there is nothing you can do about it...

I am certainly thinking about it...

Uhmm, maybe that risk could be avoided (mitigated?) on how "conservative" is that critical pre-search scan function, and even how or what can be learned in each iteration.

Also, that risk you mention is the same you have for not having the 20.0 version routine, you will always be blind to those positions, so even if the risk is there and not hurt speed, it will always favourable, I think

I suspect that prove worth because: 1) will not hurt too much the eval, and 2) will make crafty strong also in analisys mode and 3) you have access to a big cluster to test to it

[tpetzke]

Hi Fermin,

aren't you introducing big search instabilities this way because the same position will be evaluated differently depending on the flag you set in the root.

I would fear to mess up the eval cache and maybe the main hash table as well.

Thomas...

[Kempelen]

Hi Fermin,

aren't you introducing big search instabilities this way because the same position will be evaluated differently depending on the flag you set in the root.

I would fear to mess up the eval cache and maybe the main hash table as well.

Thomas...

Hi Thomas,
I think it would depend on how acurate the prediction function is. If there is a search with has no nodes with blocked positions and your function is always false, there is always a 100% acuracy, and this will be the case on 99% of root searchs.

... but if your search has nodes with blocked positions in same nodes, it is a question to find the "balance" of the function, when it tells to you 'true' when there is a real 'posibility' of gain elo, that is what I say with cluster testing.

... anyway, as I say before, I think is little speed penalty and if inaccuracy, it will be the same "blind" you have for not having the code. The more I see this scheme, the more I think it will make no danger.

Another point is that blocked positions will be very few, so is very little danger that a simple 'if' in the eval can hurt elo. But as they are few, maybe million games are needed to test te accuracy of pre-scan function.

[bob]

I have been thinking about it. But there is a risk. If you don't ALWAYS do that eval term, you might well defer it until the draw is too close to avoid. For example, locking the 4th pawn in your suggestion might be too late, as the other two pawns will become locked and there is nothing you can do about it...

I am certainly thinking about it...

Uhmm, maybe that risk could be avoided (mitigated?) on how "conservative" is that critical pre-search scan function, and even how or what can be learned in each iteration.

Also, that risk you mention is the same you have for not having the 20.0 version routine, you will always be blind to those positions, so even if the risk is there and not hurt speed, it will always favourable, I think

I suspect that prove worth because: 1) will not hurt too much the eval, and 2) will make crafty strong also in analisys mode and 3) you have access to a big cluster to test to it

Note that Crafty's eval does not "like" blocked positions, so I don't see it very often at all in real games. On the other hand, the cost of the code is real, and it is incurred in every single game, which is problematic.

[tpetzke]

Hi Fermin,

I'm not so worried about some false positives. I'm more worried about the introduction of a term that does not depend purely on the position you evaluate.

Consider the case where in the root you are close to the point where your function will return "locked paws == true" but not quite there yet. So you evaluate positions without that term, store them in the eval cache, propagate them through the tree and store them as bounds in the hash table.

With the next move you reach the point where the function returns true. Now all new positions are evaluated with that term, but they compete with positions you retrieve from the eval cache (where the term is missing). In the hash table new scores (with term) meet old bounds (without term).

I don't know whether it will become a problem in terms of ELO, but it just seems "dirty".

Of course you can design your function so that it announces locked pawns so far ahead that you can be sure nowhere in the tree you will encounter some, but how far is far enough. A 20 ply search + qSearch is changing the board significantly.

Thomas...

[Don]

Hi Bob,

About your draw closed positions code in 20.0 version, it happens to me that maybe you can mantein the code without hurting the performance too much with a little trick. Actually, every eval you do, you call this routine to trying to detect this kind of possitions. I thought that there is no need to look for this always. Before starting the root search at iteration 1, you can call a routine that will tell you if the current position has potential to have blocked positions (i.e. if its detects four or more blocked pawns). If it has, you set a flag that will let you to eval with this code, otherwise, you do normal eval. The only hurt-down is a if condition in each eval, which for me maybe is worthy.

The main idea is that a position which "looks" at the root as not closed, it will continue that way in deep searchs.

There could also be variations, i.e, you can, after each iteration, to call the routine I say above to get the flag again, with more criterions, like if the pv has no captures, or pawn moves. What you do, this routine is only called at root very few times, so no much hurt. The flag is what is important to trigger eval code.

Hope you find this interesting to test.

Kind regards and happy Christmas.
Fermin Serrano

In general we always avoid pre-processing like this due the incredible depths that programs now achieve. A search of a relatively open position might very well find closed positions. It is in interesting idea however.