move scoring

[tcusr]

why don't engines score moves right when they create them?
usually they iterate the list a second time for no reason at all, not even postponing anything. my only answer would be for simplicity but for a a few elo it doesn't seem a complicated addition.

another thing is why use a table for mvv/lva when you can do Victim - Attacker (assuming p, n, b, r, q, k ordering), less instructions and one table less.
please tell me what i'm missing,
thanks

[j.t.]

I believe I did this ages ago in my second engine, but I find it adds unnecessary code complications. Maybe not at time of coding, but as soon as you refactor things (maybe slightly different move generation, or experimenting with new move ordering scheme) you have to think about twice as many code. I haven't tested it, but I can't image that it would improve performance by a lot (please tell us if you find out otherwise ). So for me it just feels too much effort for too little reward.

[KhepriChess]

another thing is why use a table for mvv/lva when you can do Victim - Attacker (assuming p, n, b, r, q, k ordering), less instructions and one table less.
please tell me what i'm missing,
thanks

There's a good deal of past discussion on these forums that I've come across. This one, in particular, sort of addresses what you ask: https://www.talkchess.com/forum3/viewtopic.php?t=61021

In short, yes, you can do something like `PieceValue - PieceIndex`, where piece index is something like P = 1, N = 2, etc. But, important to note, what works for one engine might not work for another.

[tcusr]

I believe I did this ages ago in my second engine, but I find it adds unnecessary code complications. Maybe not at time of coding, but as soon as you refactor things (maybe slightly different move generation, or experimenting with new move ordering scheme) you have to think about twice as many code. I haven't tested it, but I can't image that it would improve performance by a lot (please tell us if you find out otherwise ). So for me it just feels too much effort for too little reward.

fair enough.
but now that i think about it this method would be useful only when generating moves in huge quantities, which means quiet moves. but since most nodes are Qnodes and most of the time (in stage move gen) the captures will cause a cut off it will be a minimal gain.

[tcusr]

another thing is why use a table for mvv/lva when you can do Victim - Attacker (assuming p, n, b, r, q, k ordering), less instructions and one table less.
please tell me what i'm missing,
thanks

There's a good deal of past discussion on these forums that I've come across. This one, in particular, sort of addresses what you ask: https://www.talkchess.com/forum3/viewtopic.php?t=61021

In short, yes, you can do something like `PieceValue - PieceIndex`, where piece index is something like P = 1, N = 2, etc. But, important to note, what works for one engine might not work for another.

interesting thread, it cleared a few doubts
thanks

[hgm]

I always score the captures during move gen. E.g. in KingSlayer the move generator examines the to-square to determine whether the move is pseudo-legal, and that naturally branches the code in a capture and non-captur e section. Captures are then scored and added to the top of the move list, non-captures are added at the end. At that point any has move would already have been searched.

[mvanthoor]

why don't engines score moves right when they create them?
usually they iterate the list a second time for no reason at all, not even postponing anything. my only answer would be for simplicity but for a a few elo it doesn't seem a complicated addition.

First: you will need to run through the move list anyway to order or pick moves, because you can't know which of the moves in the list are going to be the transposition table move, or are part of the killer moves. (If any, obviously.)

Second: responsibilities. your move ordering code should not be conflated with the move generator code. It might be a tiny tad faster, but not enough to gain more than a few Elo points. It's not worth it to start mixing up code.

[hgm]

First: you will need to run through the move list anyway to order or pick moves, because you can't know which of the moves in the list are going to be the transposition table move, or are part of the killer moves. (If any, obviously.)

Not necessarily. In fact you might not even need a move list. E.g. you can organize captures as a bitmap, where each of 256 bits (16 possible attackers x 16 possible victims) represents a capture, and gets set when that capture gets generated. If you assign the bits in MVV/LVA order, you can then just extract the 1 bits, and immediately search it. No need to assign any sort key. You can test whether a move was the hash move just before you search it. And you might not even need to do that, because when you try to search the hash move a second time the result from the first time stored in the TT would give you a hash cutoff that fails low. You can rely on that to suppress duplicat searches. Also for the killers, which would become an issue only after you searched the captures.

So you can just play the hash move before any move generation, and the killers (after checking their pseudo-legality) before non-capture generation. Running through the move list is a needlessly expensive method for testing wheter a move is pseudo-legal; a little bit of dedicated code (e.g. a lookup by toSqr-fromSqr to see if the step matches the piece type, and a test for blocking) would be far faster.

[JohnWoe]

I score moves in movegenerator. Only captures + promotion + pawn push on 7th etc. I don't score all moves. Those not scored and still good. Will be in the hashtable and searched first. The next iteration.

Then just LazySort() the highest move.

Staged movegenerator makes no sense in chess. Very few moves. Propably worth +1 Elo.If your movegenerator is fast. In 10x8 Capablanca/ Shogi maybe with 60+ moves.

I get 56 MNPS from starting position. Legal moves, scored.

[Luecx]

Staged movegenerator makes no sense in chess. Very few moves. Propably worth +1 Elo.If your movegenerator is fast. In 10x8 Capablanca/ Shogi maybe with 60+ moves.

Just because yours seems to be bad, you cannot generalize that.

EDIT:

I am actually impressed by your comment history but i assume this comment just sums it up pretty well:

At least +350 Elo stronger than Sapeli 1.92. This proves that handcrafted evaluations are all crap.