No PVS at low depths?

[mjlef]

I see the sample engine at chessprogramming.wikispaces.com does not use PVS at low depths (depth<=2). I assume the idea is bad move ordering near the horizon could lead to too many researches at low depths. Has this been tested? What about in the qsearch? In the qsearch, I assume move ordering (once away from no capture checking moves) woudl be very good, and might benefit from PVS, but has this been tested? What did you find?

Mark

[Teemu Pudas]

Fruit does this in quiescence. I think part of the point is that a PVS re-search would throw away all the work because QS isn't hashed.

[bob]

I see the sample engine at chessprogramming.wikispaces.com does not use PVS at low depths (depth<=2). I assume the idea is bad move ordering near the horizon could lead to too many researches at low depths. Has this been tested? What about in the qsearch? In the qsearch, I assume move ordering (once away from no capture checking moves) woudl be very good, and might benefit from PVS, but has this been tested? What did you find?

Mark

I do it everywhere myself...

[mjlef]

I see the sample engine at chessprogramming.wikispaces.com does not use PVS at low depths (depth<=2). I assume the idea is bad move ordering near the horizon could lead to too many researches at low depths. Has this been tested? What about in the qsearch? In the qsearch, I assume move ordering (once away from no capture checking moves) woudl be very good, and might benefit from PVS, but has this been tested? What did you find?

Mark

I do it everywhere myself...

Have you tested with and without it at varying depths? A test fo say no PVS in qsearch and then no PVS for depth <=X with X=1, 2, 3.. would be interesting. We want to keep all your cores busy! I assume at some point if move ordering is less than ideal, it might save nodes. But maybe move ordering is so good, PVS always pays off.

[michiguel]

I see the sample engine at chessprogramming.wikispaces.com does not use PVS at low depths (depth<=2). I assume the idea is bad move ordering near the horizon could lead to too many researches at low depths. Has this been tested? What about in the qsearch? In the qsearch, I assume move ordering (once away from no capture checking moves) woudl be very good, and might benefit from PVS, but has this been tested? What did you find?

Mark

I do it everywhere myself...

Have you tested with and without it at varying depths? A test fo say no PVS in qsearch and then no PVS for depth <=X with X=1, 2, 3.. would be interesting. We want to keep all your cores busy! I assume at some point if move ordering is less than ideal, it might save nodes. But maybe move ordering is so good, PVS always pays off.

I am skeptical that this trick would save much. The only place in which you have beta > (alpha+1) is at the principal variation. Therefore, the only place in which this happens at the Q search is at the tip of the principal variation. That is only a handful of nodes. Everywhere else in Qsearch beta == (alpha+1), so this is making no difference. Doing this at deeper depths may make more sense, but still I do not think it is a lot of nodes. All of these cases are too close to the principal variation.

Miguel

[bob]

I see the sample engine at chessprogramming.wikispaces.com does not use PVS at low depths (depth<=2). I assume the idea is bad move ordering near the horizon could lead to too many researches at low depths. Has this been tested? What about in the qsearch? In the qsearch, I assume move ordering (once away from no capture checking moves) woudl be very good, and might benefit from PVS, but has this been tested? What did you find?

Mark

I do it everywhere myself...

Have you tested with and without it at varying depths? A test fo say no PVS in qsearch and then no PVS for depth <=X with X=1, 2, 3.. would be interesting. We want to keep all your cores busy! I assume at some point if move ordering is less than ideal, it might save nodes. But maybe move ordering is so good, PVS always pays off.

I do not do it in q-search at all, but I do it at all depths > 0.