SEE logic

[hgm]

HGM made a point. It apparently went over your head.

I can't say there wasn't a word of Chinese in it, though.

Apparently that was the problem.

[bob]

I guess you will be remembered as "just someone who is annoying as hell"?

HGM made a point. It apparently went over your head. You have been arguing over your head since then.

I won't be remembered.


I was talking of chess and I stated it clearly (no poker, etc). HGM argumentation were just bla bla. You even didn't reached bla bla level in your post.

Neither did you, if you read what you wrote. Just an insult tossed out for no discernible reason...

[hgm]

Well, he had not reached his daily minimum of snide remarks yet, so you just got one for free.

[Ralph Stoesser]

Regarding this idea, when used in chess (not in Xiangqi, backgammon or poker) I would be very surprised if it works, mainly it makes no sense to me because position evaluation and SEE are 2 quite orthogonal concepts

It depends what one SEE uses for. In case one uses it for ordering of captures only, it might be logical and usefull to add additional knowledge to SEE to be able to more often make successful tie-breaks between two (pure) SEE-equivalent captures. If you have two good captures pawn x pawn and you have to decide which one you should try first for a maximum likelyhood to get a cut off, why not use some knowledge based heuristic instead of let coincidence(move generator) decide, if it costs "nothing"? From chess playing experience we know that in general it is better to capture into the center than to the border side with pawns. Of course all depends on the specific position but it is enough to more often make the right decision than the wrong one to be able to shrink the tree size a little for no extra cost. Therefore I think this and similar ideas are very logical in principle and worth a try or 10, also for good old chess.

[Harald]

I don't think that PSQ will help a lot because there are a few cases when PSQ difference will cost at least one pawn.

Then use piece_square_table_value / 4 instead of piece_square_table_value.
That could make a difference and not waste a pawn.

[hgm]

I think he worries about exactly the opposite. What you propose would make even less difference than using full PST. And if it doesn't make any difference, it cannot be better.

What you call 'wasting a Pawn' is actually exactly what could make it better. When 'wasting a Pawn' would give you a better evaluation score, pruning the move, or searching it last because it has negative SEE does not seem very sensible.

In Chess this could for instance happen with 6th or 7th-rank Pawns. If your evaluation values a 7th-rank Pawn as, say, 250 and a 6th-rank Pawn protecting it as 150, NxP PxP RxP on the square of the former would trade a Knight (325) for 400 in Pawn material, which seems a good deal. There seems little advantage in pruning that move, or sorting it last (to put it mildly). Yet this is exactly what a SEE with fixed conventional piece values would do (N for 2P = -1).

SEE is used to get a cheap preview of what a move will earn or lose evaluation-wise, on which you can base search decisions. And counting victims that will earn you 250 as 100 will not do much for its accuracy.