Splitting PVS

[outAtime]

Ive seen alot of programs splitting the PVS between search and searchPV.
What happens in a case where the PVS in root calls only one routine everywhere (search) and then the PVS in search() also only calls search?
Does this mean the engine is _always_ searching the PV? I cant really imagine this could be so, but if not, how can it be distinguished when the PV is not being searched? I was thinking about adding some flags in the root PVS and in search() when its not the first move or a fail high reasearch, but then Id still be doing -alpha, alpha everywhere else and not just a strict -beta type search so that is why I was wondering if Im always searching the PV in some way. A bit confused I guess if a strict -beta routine is neccesary to NOT search the PV. Thanks.

[outAtime]

Ok, so I tried a little experiment by adding && !searching_pv in root_search():

Code: Select all

/* go deeper if it's a legal move: */

    if (check_legal (&moves[0], i) && !searching_pv) {
    
    root_score = -search(-beta, -alpha)
    etc..

The search was completely broken. No output. Then I removed the condition from root_search() and added it in the same place to search(). This time the search worked, so that must mean that search() is _never_ searching the PV. Right?

Therefore I'm guessing that root_search() when compared to a split PVS would = root_search + PVsearch, and search() = search(). Am I right here?

[outAtime]

It just seem wrong, the flags must be broken or something.

[outAtime]

Added (&& searching_pv) condition to search() and it broke, which I think confirms _everything_ was getting through the !searching_pv condition. So either search() is never searching the PV (is that possible? search_root() only calls search() and there is nothing else) or the flag is broken in as much as it can't be used for a condition. If the flags are broken then I think that would mean there is a bug in Sjeng 11.2 because there are !searching_pv conditions in null move and I think in razoring as well and the is_pondering = TRUE/FALSE stuff is all in the same places. I will try to think of some other tests to confirm this condition isn't working....

[Richard Allbert]

In the root, you'll always start searching the PV - your current best move (from the previous iteration).

I'm not on my normal computer at the moment, but IIRC Faile (or Sjeng 11.2) sets a searching PV = TRUE flag at the start of each iteration.

So, if you add a flag saying don't search if (searching_pv) in the root, nothing will be searched.

Richard

[outAtime]

Yeah, Its fairly apparent to me now that searching_pv = TRUE for all moves in root_search(), and thats why it broke when I added the !searching_pv condition there before searching any moves. My question really started out as how to distinguish if the engine is searching the PV or not, and I gradually began to realize that the !searching_pv condition seems to have no effect on anything in search(). Actually, I don't even know why this flag is here at the moment except perhaps for move ordering, but even that may not be working as intended. Im also doubting that !searching_pv conditions found in (Faile dosen't use any condition like this) Sjeng 11.2 search() are working as intended because adding that to search() like I did in root_search dosen't break anything. As well as potentially debugging some old code, what I'd really like to learn is if the flag might work better if set outside of score > alpha as suggested by CPW (see pvs) or otherwise to distinguish when the PV is being searched. Setting searching_pv outside score > alpha would seem to suggest that the PV is being searched until somthing gets above alpha, which I dont quite fully understand yet, but it seems to make sense. So basically to get a PVS with LMR working (it works already, but not as I intended) I need to figure out somehow to find the PV, and to count it. So far I was using !searching_pv condition and some counters in the loop, but I have a feeling I might need to redo the thing a bit to have this flag working, if it really isn't. My other question which seems to me a bit silly, was if it was possible that search() does not search the PV, even though it is called by root_search(). If that was true then my job would be alot easier.

[outAtime]

I think maybe my ideas were wrong because if I count only the nodes in LMR in root_search() with the added condition !searching_pv, there are still nodes being counted... I always knew this... therefore I guess root_search isn't always searching the PV. I apologize for my confusion in this, but Im really trying to learn! So is the PV only searched from the root on the first move? I thought is was longer. When I added !searching_pv to search() it didn't seem to break which made me think search() was _never_ searching the PV, but I guess it does too, who knows?. I thought root search only searched the root and the PV. Maybe I got confused by programs which have root_search and search_PV and search. I just can't figure out how those 3 relate to Faile's root_search and search.

[outAtime]

I think I'll move this to another thread because it seems to be less about Splitting the PVS and much more about understanding how this PV flag works. Thanks