SEE logic

[Sven]

It doesn't cost anything extra to fetch the value as PST[sqr] compared to value[piece].

I almost agree, although most programs usually have something like PST[piece][sqr] which has a slightly higher cost due to the two-dimensional array access.

[mcostalba]

Some of my engines use PST values too to qualify captures as good, bad or dubious. (I usually don't do a full SEE.) It doesn't cost anything extra to fetch the value as PST[sqr] compared to value[piece]. Especially in Xiangqi, where the value of a piece is wildly dependent on where it is located, this makes a lot of sense.

This is the typical flawed kind of logic that people wishing to develop a chess engine should avoid, in particular:

Code: Select all

"It doesn't cost anything"  +  "makes a lot of sense"  != useful patch

Only tests should validate a code addition.

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, aimed at different targets.


P.S: Sorry to use you as a poster child of what people should not do, it just happened I looked at your post this morning.

[syzygy]

This is the typical flawed kind of logic that people wishing to develop a chess engine should avoid, in particular:

It's not flawed logic. It makes sense to spend some time thinking about an idea before blindly running tests. But of course only tests will show whether it works in a particular engine or not.

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, aimed at different targets.

Typical flawed logic?

[lucasart]

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, aimed at different targets.

Maybe it can work in PacMan or Tetris

[Evert]

If you store piece values as part of the PST it does of course make sense. Xiangqi is also a bit special in that it depends very much on the stage of the game whether cannon for knight is a good trade or not.

I would be worried that a bad capture will look good just because of piece placement. If the pieces were placed differently the same exchange would not look so good. Of course SEE is usually not the final verdict on a move, it just changes our expectation of whether a move will turn out to be good or not, so it's not a complete disaster to get it slightly wrong. For move ordering it probably does make sense to include the PST in the ordering, since SEE+ΔPST is a better approximation to Δeval than SEE alone. Whether it makes a significant difference would need to be tested of course.

[Michel]

It's not flawed logic. It makes sense to spend some time thinking about an idea before blindly running tests. But of course only tests will show whether it works in a particular engine or not.

Also people often invert this logic which is of course wrong. The fact that a test fails does NOT mean the idea is wrong. The implementation may simply require tuning.

Without proper tuning you may be comparing a fully tuned steam machine with a badly tuned combustion engine.

Unfortunately tuning is by far the most difficult part of chess engine development. I just did a tuning session of 3 parameters with CLOP and it took 500000 games before there seemed to be convergence.

[Sergei S. Markoff]

From all the posts here i got the impression that everybody uses just captured piece values in SEE.

But i set-up my SEE to also include piece-square values of all the moves made. It is definitely slower, but i think it adds a lot of value. But i never tested impact of this on engine playing strength.

Does anybody else include PST values in SEE score? Have anybody tried this approach? Any thoughts?

Thanks.

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.
But what is really worth to try is to use material imbalance table.

[hgm]

Code: Select all

"It doesn't cost anything"  +  "makes a lot of sense"  != useful patch

Only tests should validate a code addition.

That might be an attitude you can afford when merely patching someone else's code that is already strong for doing the same task, but when writing original code for a new task, it wouldn't get you very far...

[mcostalba]

Code: Select all

"It doesn't cost anything"  +  "makes a lot of sense"  != useful patch

Only tests should validate a code addition.

That might be an attitude you can afford when merely patching someone else's code that is already strong for doing the same task, but when writing original code for a new task, it wouldn't get you very far...

No, this attitude is the correct one at any level of software development: first you have to start with the simplest way then start adding stuff /features only if they work. In this case we are talking of SEE, a well known and well described algorithm, so let's just write the simplest SEE version then tweak it if it worth. That's the correct attitude of software development.

Inventing and hence coding complex stuff from scratch might be an attitude you can afford when developing as an amateurish and assuming to understand very well what you are doing (the latter is a synonym of developing as an amateurish).


Note that I use the word "amateurish" not in opposition to "professional", but to "serious".

[hgm]

The correct attitude would be to start from common knowledge about the task you want to program, rather from absolute nonsense just because it is simpler. Starting from a SEE where all pieces are given value 1, because that is 'simpler' than making the piece value depend on the type of piece, and then insisting that a Rook can only be given a different value if it is first determined by extensive testing for what the optimal value would border on idiocy. Likewise would insisting that pieces must be assigned a location-independent value for simplicity of the calculation, in a game where it is known that location is all-important be madness.

It is always better to start from things that make sense, than to start from idiocy, and insist on excessive testing before it should be allowed to replace the idiocy by something decent. The effect of gross misjudgements is often not additive, they can easily mask each other. If a program only starts playing decently when you get both A and B right, starting with both of them wrong would forever prevent you from fixing the problem when you required prove that fixing A improved matters while B was still wrong, and fixing B improved matters while A was still wrong. (Try how much good fixing the sign of the evaluation wil do when the Q/P ratio is set to 1/9, or how much good setting the Q/P ratio to 9 will do if you still have the wrong sign in the evaluation.) And in real life 10 independent things might have to be all correct before you can expect sensible behavior...

Starting from nonsense is a bad idea, and the fact that it might be simple nonsense does not improve that.