about researches

[Engin]

yes, i do the same way now, what done a pre-research with zero windows and full depth first before i do full window, full depth.

i prefer in root and pv nodes score > alpha, and for non pv nodes i use score >= beta.

ok, other question is how deep is your reductions in pv nodes or non pv nodes, i think the reduction in SF are a little bit high for me, so i decide to reduce in pv nodes only one ply and in non pv nodes even 2 plies, more then 2 plies i thought is little dangarous, because the engine its missing then some tactical moves if is to much high reduced.

[Chan Rasjid]

What are your conditions for doing researches for a reduced move.
a) score > alpha or score >= beta
I am doing the first but I guess this doesn't matter much inside the tree as most nodes there are non-pv.

b) retrieve the whole depth at once or do it iteratively. I do the second which means if the move is reduced by 4, i do 3 researches...

c) if the move is reduced and window is zeroed, which do you do first ? research with full window, and then with full depth ? or the opposite ?
or both at the same time. I do the first because i think changing the window changes the search space more than changing the search depth.

I find that these decisions are rather important especially at the root ?
thoughts?

Daniel

a. I use >= beta.

b. I do not follow the question.

c. On a reduced move that returns v >= beta, re-search without reduction. Certainly before you try the wide window re-search which. Re-searching the null-window first would be pointless. You could not trust it if it fails high, until you restore the depth. So start there first to avoid wasted time.

a) your >= beta is ok provided beta = alpha+1. But the idea of LMR is we assume a reduced_depth fail-low is good enough; a normal research is needed if x > alpha - so the correct test is x > alpha.
b) say, for high reduction of 4, it may fail-low implying a normal full research; but if it had been reduced with a lesser depth of 3/2, it may pass the LMR fail-low test which does not need a normal research; Richard Vida didn't seem to find gains in it; since at a reduced depth(any) it does not fail low, the probability is there that it is better to use a full_width_full_depth research.

Rasjid

[Daniel Shawul]

Critter 0.8:
Research with zero window full depth first, if this fails high then research again with full window full depth

Critter 0.9:
Research immediately with full window full depth, except at root.

So you noted that too At the root these decisions are very crucial it seems.
Not doing researches is better than doing it badly. At first I got the order wrong (first full window, then iteratively incremented depth), which performed badly.

Correction: In my previous post in (b) , I mentioned things wrong

root : iteratively research with depth incremented, then full window
elsewhere : opposite of root

This makes absolutely no sense to me. What makes the root behave the opposite of all other nodes? Nothing I can think of. I do it the same everywhere. And don't even have a separate SearchRoot() function any longer in Crafty.

I have no reason to change the order inside tree. What is done at the root should work there too. But the fact that we have very few pv nodes in there makes things unmeasurable which is why i left it as it is. But I did notice the significance of doing things correctly at the root.

Daniel

If you read just one line more, I said I have no reason. So why the echo ?

[Daniel Shawul]

a) I believe score > alpha is appropriate, because the move has exceeded the best expectation for an assumed fail low node. Why does it have to exceed beta too? I always understood this decision of using beta instead of alpha as a way to avoid many researches.
For a non-pv node they are the same as I have already mentioned.

b) if you do two or more reductions, how do you do the research? By retrieving the whole depth at once Or incrementing it by a small amount.
Doing the first one at the root really made it weaker, hence my question.

c)

[Mangar]

Hi Bob,

there is no big issue but you can do several things at root you wouldn´t do in deepter searches. I suppose you have an aspiration window that chainges on fail high/low in root. I have tried the following things:

* Move ordering: PV move is searched first, then all "earlier pv" movesare searched. All other moves are ordered by the amount of nodes searched.
* If I research a move that was searched as pv move earlier at current depth (with a smaller aspiration window) I research it with "pv" settings (full window, full depth) instead of trying a null window search or a lower depth search first.
* I have a small aspiration window. On fail low Spike searches at all other moves only if the pv move failed low twice.
* I save all informations Spike collected on a root move search like its PV. For example Spike may have an old pv line from previous search (lower depth, different window) of a move. If this move will be searched I can use this pv line (store it to hash again to make sure it is not overwritten).
* Spike supports multi-pv analyse, this has an impact on root search.

Thus I think there are many useful things to do at root that are much more compicated at "inner nodes".

Greetings Volker

[Daniel Shawul]

He means at PV nodes. For non-pv nodes they are both the same.

[bob]

Critter 0.8:
Research with zero window full depth first, if this fails high then research again with full window full depth

Critter 0.9:
Research immediately with full window full depth, except at root.

So you noted that too At the root these decisions are very crucial it seems.
Not doing researches is better than doing it badly. At first I got the order wrong (first full window, then iteratively incremented depth), which performed badly.

Correction: In my previous post in (b) , I mentioned things wrong

root : iteratively research with depth incremented, then full window
elsewhere : opposite of root

This makes absolutely no sense to me. What makes the root behave the opposite of all other nodes? Nothing I can think of. I do it the same everywhere. And don't even have a separate SearchRoot() function any longer in Crafty.

I have no reason to change the order inside tree. What is done at the root should work there too. But the fact that we have very few pv nodes in there makes things unmeasurable which is why i left it as it is. But I did notice the significance of doing things correctly at the root.

Daniel

If you read just one line more, I said I have no reason. So why the echo ?

If you do things for "no reason" then you have a limit to your success that is not going to be very high. _Everything_ I do I do for a reason. As I said, treating the root different from other nodes makes zero sense. So there is a reason to make them match. How is the root different??

[bob]

Hi Bob,

there is no big issue but you can do several things at root you wouldn´t do in deepter searches. I suppose you have an aspiration window that chainges on fail high/low in root. I have tried the following things:

* Move ordering: PV move is searched first, then all "earlier pv" movesare searched. All other moves are ordered by the amount of nodes searched.
* If I research a move that was searched as pv move earlier at current depth (with a smaller aspiration window) I research it with "pv" settings (full window, full depth) instead of trying a null window search or a lower depth search first.
* I have a small aspiration window. On fail low Spike searches at all other moves only if the pv move failed low twice.
* I save all informations Spike collected on a root move search like its PV. For example Spike may have an old pv line from previous search (lower depth, different window) of a move. If this move will be searched I can use this pv line (store it to hash again to make sure it is not overwritten).
* Spike supports multi-pv analyse, this has an impact on root search.

Thus I think there are many useful things to do at root that are much more compicated at "inner nodes".

Greetings Volker

Yes, but you would not do something one way at the root, and the opposite way in the normal search. I don't consider aspiration search to be a root issue. That window is set _before_ I call search at all. Ditto for multi-PV.

Failing low or high at the root is something that is again "outside the root" of the tree. Whether you call search multiple times to deal with multi-PV, whether youi relax a bound incrementally or in one big jump, is all something that is done outside the search itself, in the implementations I have done (or in the ones I have looked at carefully).

[bob]

a. I use >= beta.

I guess it's time you spin your cluster on "score > alpha"

I looked at the code and I actually use value > alpha, which is value>=beta for non-PV nodes. I think I used value >= beta at first, but that can cause a short PV because a reduced search can return v > alpha and v < beta, which would accept the value without a full-depth re-search...

That is such a rare happening, however (value > alpha && value < beta)...

[bob]

What are your conditions for doing researches for a reduced move.
a) score > alpha or score >= beta
I am doing the first but I guess this doesn't matter much inside the tree as most nodes there are non-pv.

b) retrieve the whole depth at once or do it iteratively. I do the second which means if the move is reduced by 4, i do 3 researches...

c) if the move is reduced and window is zeroed, which do you do first ? research with full window, and then with full depth ? or the opposite ?
or both at the same time. I do the first because i think changing the window changes the search space more than changing the search depth.

I find that these decisions are rather important especially at the root ?
thoughts?

Daniel

a. I use >= beta.

b. I do not follow the question.

c. On a reduced move that returns v >= beta, re-search without reduction. Certainly before you try the wide window re-search which. Re-searching the null-window first would be pointless. You could not trust it if it fails high, until you restore the depth. So start there first to avoid wasted time.

a) your >= beta is ok provided beta = alpha+1. But the idea of LMR is we assume a reduced_depth fail-low is good enough; a normal research is needed if x > alpha - so the correct test is x > alpha.
b) say, for high reduction of 4, it may fail-low implying a normal full research; but if it had been reduced with a lesser depth of 3/2, it may pass the LMR fail-low test which does not need a normal research; Richard Vida didn't seem to find gains in it; since at a reduced depth(any) it does not fail low, the probability is there that it is better to use a full_width_full_depth research.

Rasjid

(a) I checked the code and I do use v > alpha, which prevents a reduced-depth PV from popping out now and again.

(b) I am not yet playing with really big LMR numbers. That is my next series of tests to run once I do some testing on trying to order the moves beyond captures killers and such.