Somethings wrong but where (lol)

[Sven]

Please look at my code and give your advice about my PV / LMR and NUlmove method.

Also : do you think if it is normal the search drop from depth 16 to 12 when just adding pst ?
Or my move ordering is may be bad ?

Your question about the search depth dropping from 16 to 12 has already been answered: yes, it is normal, considering the jump in eval quality from "material only" to "material + PST". I can't say much about your move ordering. You use MVV/LVA, it seems you do not use the TT hash for move ordering yet, but since your effective branching factor does not look too bad I would assume that you do not have a move ordering problem at the moment.

So far PV handling looks normal to me. Your short PVs are not unusual, they probably result from using the TT hash so almost everyone suffers from it. If you reach a position P for the first time and you do a regular tree search you get back a (local) PV. Maybe later it turns out that P and its local PV become part of the root PV. Now after a while (within the same iteration at root) you reach again P through a transposition and your hash table allows to avoid another tree search, returning a score from TT instead. But the former local PV of P is lost in the meantime. For some reason the new path to P becomes your new root PV but now it ends at P already and is shorter than the current search depth at root.

There might as well be other similar reasons for getting short PVs. A possible way to avoid most of them is to maintain a small PV hash table, a concept of which I know that it has been applied successfully by Bob Hyatt at least.

What I found in the code you posted is that you apply the check extension after having tested for depth <= 0. This means that you do a normal qsearch even in a depth=0 position where your king is currently in check. You might get in trouble that way, at least iteration N will usually not find a mate in N plies. I suggest to check for depth <= 0 after possibly applying a check extension.

[mar]

What I found in the code you posted is that you apply the check extension after having tested for depth <= 0. This means that you do a normal qsearch even in a depth=0 position where your king is currently in check. You might get in trouble that way, at least iteration N will usually not find a mate in N plies. I suggest to check for depth <= 0 after possibly applying a check extension.

When in check qsearch will search all evasions (mine will for sure), so it will certainly find if stm gets checkmated at depth 0.

[Sven]

What I found in the code you posted is that you apply the check extension after having tested for depth <= 0. This means that you do a normal qsearch even in a depth=0 position where your king is currently in check. You might get in trouble that way, at least iteration N will usually not find a mate in N plies. I suggest to check for depth <= 0 after possibly applying a check extension.

When in check qsearch will search all evasions (mine will for sure), so it will certainly find if stm gets checkmated at depth 0.

Right. But some qsearch implementations do so and others don't. And even if you do so it might save one function call per "depth==0" node to avoid entering the qsearch function when actually an evasion search is needed. In my engines I usually have different search functions for full-width search, evasion search, and quiescence search. A near-to-optimal strategy would also detect whether a move is giving check before making it on the board, and always call the appropriate function depending on that information and on the remaining depth.

[Daniel Anulliero]

What I found in the code you posted is that you apply the check extension after having tested for depth <= 0. This means that you do a normal qsearch even in a depth=0 position where your king is currently in check. You might get in trouble that way, at least iteration N will usually not find a mate in N plies. I suggest to check for depth <= 0 after possibly applying a check extension.

Thanks Sven to pointed out that ! It's very logical to check if depth <= 0 AFTER checking the check extension ! I'll change that but of course it need some tests to see if it's better !
Now I rewrite my eval because I'm not satisfied with it
Thanks again !

[mar]

Thanks Sven to pointed out that ! It's very logical to check if depth <= 0 AFTER checking the check extension ! I'll change that but of course it need some tests to see if it's better !
Now I rewrite my eval because I'm not satisfied with it
Thanks again !

Why are you trying to fix something that isn't broken?
I find it logical to drop to qs asap (and also more readable).
If you allow to stand pat in qs when in check then you should fix your qs (bonus: you improve your qs and you never call eval when in check [which is good to know])
Also, how do you extend checks? Do you extend moves giving check or do you extend evasions from check? I would prefer the former.

So if you do the former and say extend moves giving check a full ply, then delaying qs call "saves" nothing.
Delaying qs is a micro-optimization (if at all) that saves you a qs call:
- if you extend check evasions, not moves giving check
- iff you find out you're checkmated at depth 0
Now how often does the second case happen and how much does it save? => my bet is nothing that could be even measured
If you extend moves giving checks less that 1 ply, case 2 can still hapen (but with even lower probability)

[Daniel Anulliero]

Thanks Sven to pointed out that ! It's very logical to check if depth <= 0 AFTER checking the check extension ! I'll change that but of course it need some tests to see if it's better !
Now I rewrite my eval because I'm not satisfied with it
Thanks again !

Why are you trying to fix something that isn't broken?
I find it logical to drop to qs asap (and also more readable).
If you allow to stand pat in qs when in check then you should fix your qs (bonus: you improve your qs and you never call eval when in check [which is good to know])
Also, how do you extend checks? Do you extend moves giving check or do you extend evasions from check? I would prefer the former.

So if you do the former and say extend moves giving check a full ply, then delaying qs call "saves" nothing.
Delaying qs is a micro-optimization (if at all) that saves you a qs call:
- if you extend check evasions, not moves giving check
- iff you find out you're checkmated at depth 0
Now how often does the second case happen and how much does it save? => my bet is nothing that could be even measured
If you extend moves giving checks less that 1 ply, case 2 can still hapen (but with even lower probability)

Because the idea of Sven seemed more logical to me , my qs is very basic , no check tests, no delta prunning etc...I think with a primitive qs you can't enter in QS when in check , too dangerous no?
Well I extend when the side to move is in check , so I extend évasions from check.
Can we extend twice ?

[mar]

Because the idea of Sven seemed more logical to me , my qs is very basic , no check tests, no delta prunning etc...I think with a primitive qs you can't enter in QS when in check , too dangerous no?
Well I extend when the side to move is in check , so I extend évasions from check.
Can we extend twice ?

I see now, so in your case Sven's idea will be indeed beneficial for you, because right now you can enter qs when stm is in check.
I assume you don't handle evasions in qs.
Handling evasions in qs is a good thing, because it allows you to detect checkmates in qs (say queen contact checkmate after a capture).
By extending twice you mean extending both moves giving check and evasions? I'm afraid that would explode your search (assuming you would extend both a full ply).

Knowing in advance if a move gives check is also useful for for making pruning/reduction decisions,
like not fpruning or reducing moves that give check (you could then experiment with things like pruning bad SEE checks at low depths; I don't do this but some do IIRC)

[Daniel Anulliero]

Because the idea of Sven seemed more logical to me , my qs is very basic , no check tests, no delta prunning etc...I think with a primitive qs you can't enter in QS when in check , too dangerous no?
Well I extend when the side to move is in check , so I extend évasions from check.
Can we extend twice ?

I see now, so in your case Sven's idea will be indeed beneficial for you, because right now you can enter qs when stm is in check.
I assume you don't handle evasions in qs.
Handling evasions in qs is a good thing, because it allows you to detect checkmates in qs (say queen contact checkmate after a capture).
By extending twice you mean extending both moves giving check and evasions? I'm afraid that would explode your search (assuming you would extend both a full ply).

Knowing in advance if a move gives check is also useful for for making pruning/reduction decisions,
like not fpruning or reducing moves that give check (you could then experiment with things like pruning bad SEE checks at low depths; I don't do this but some do IIRC)

I didn't know qs was much important maybe more than the search ?
Now I have some works on Qs too !
For the moment I play a test match Isa "hgm tourney" vs an Isa with the sven's "fix" and a poor eval (material ,mobility , isolated and doubled pawn , rooks on open files)
TC : blitz 5'+1"
Score 19.5-17.5 for the version test .The test continue , too few games to say if it is an improvment but it is encouraging
bests
dany
ps : If you want Martin I'll post my Qs function too

[mar]

I didn't know qs was much important maybe more than the search ?
Now I have some works on Qs too !
For the moment I play a test match Isa "hgm tourney" vs an Isa with the sven's "fix" and a poor eval (material ,mobility , isolated and doubled pawn , rooks on open files)
TC : blitz 5'+1"
Score 19.5-17.5 for the version test .The test continue , too few games to say if it is an improvment but it is encouraging
bests
dany
ps : If you want Martin I'll post my Qs function too

I wouldn't say qs is more important than search. But I'd say it's essential to have qs, I'm pretty sure that without qs elo would drop a lot. Without qs you might also experience even-odd effect (at least I think I did experience this).
Having a good qs is an improvement over basic qs.
I generate all evasions in qs when in check, I also generate checks at depth 0 (and I even hash qs).

There are pathological positions that could explode the qs though, so that you'd need a lot of time to even finish first iteration of iterative deepening.
I solved this by introducing a "minimum qs depth", which I simply compute as -3*root_depth (arbitrary constant that worked well for me).
Whenever I reach depth below minimum qs depth (and stm is not in check), I simply return static eval.
The idea might not be great (it certainly won't get any elo) but seems to work well in practice (avoids pathological cases of qs explosion).

[Henk]

I just added a cheap mobility for knight and bishop and what happens it scores significant lower on the WAC test. I don't think it has to do with losing speed but with losing depth.

It also scored significantly higher on positional tests but it looks like that does not compensate when I see the games it plays. I think tactics are more important. I did not measure ELO.

So that means material only or what else ?