hgm wrote: ↑Mon Feb 07, 2022 10:39 pm
If mobility alone is not enough, this suggest there is something fundamentally wrong in the mobility eval. Because the only reason for pushing that Pawn is to give the Bishop mobility.
The aspect that conventional mobility evaluation (i.e. proportional to the number of moves) fails to take into account, is that several moves in the same direction are likely worth less than moves in different directions, and no moves in any direction is exceptionally bad.
with mailbox it's easy, decrement the bonus while advancing to the direction.
i don't know how i would do it with bitboards
With bitboard you just look up a bitboard with all moves in a hash table, and apply the popcnt instruction to it.
'Easy' is not the same as fast.
And both methods just give you the number of moves. So they don't take account for how these moves are distributed over various directions. My point was that the specialized evaluation of Chess960 Bishop trapping are just a kludge to repair that for a frequently occurring (in Chess960) case.
hgm wrote: ↑Mon Feb 07, 2022 10:39 pm
If mobility alone is not enough, this suggest there is something fundamentally wrong in the mobility eval. Because the only reason for pushing that Pawn is to give the Bishop mobility.
The aspect that conventional mobility evaluation (i.e. proportional to the number of moves) fails to take into account, is that several moves in the same direction are likely worth less than moves in different directions, and no moves in any direction is exceptionally bad.
with mailbox it's easy, decrement the bonus while advancing to the direction.
i don't know how i would do it with bitboards
With bitboard you just look up a bitboard with all moves in a hash table, and apply the popcnt instruction to it.
'Easy' is not the same as fast.
And both methods just give you the number of moves. So they don't take account for how these moves are distributed over various directions. My point was that the specialized evaluation of Chess960 Bishop trapping are just a kludge to repair that for a frequently occurring (in Chess960) case.
i know how to calculate mobility for bitboards or mailbox, what i suggested was way to favor mobility in multiple directions.
the mobility bonus decreases that more you move away from the starting square.
tcusr wrote: ↑Tue Feb 08, 2022 11:52 pm
i know how to calculate mobility for bitboards or mailbox, what i suggested was way to favor mobility in multiple directions.
the mobility bonus decreases that more you move away from the starting square.
Ah, OK, I misunderstood that. Indeed, when you add a bonus for each target square encountered in a ray-scan loop, you could lower the bonus after the first iteration.
Such looping makes mobility quite expensive to calculate, though. In a bitboard design you could tabulate the mobility bonus directly, rather than feed the tabulated attack sets to popcnt. That would give you ultimate flexibility for how to score the various numbers of moves in the various directions. With mailbox I prefer to keep track of mobility incrementally. (Most pieces keep excatly the same mobility after a move, and it seems wasteful to determine their mobility with slow loops over and over again...) To get flexible scoring you can incrementally keep track of the number of moves they have, and whenever that changes, use it in a small lookup table to get the new bonus (after subtracting the old bonus, which you also keep track of). If you want to give an extra penalty when the piece can only move in one dimension, and has no moves orthogonal to it, you could incrementally update a linear combination of the moves in different dimension (rather than just their sum), like 7*vertical + horizontal for a Rook. And use that to index a somewhat larger table with scores.
tcusr wrote: ↑Tue Feb 08, 2022 11:52 pm
i know how to calculate mobility for bitboards or mailbox, what i suggested was way to favor mobility in multiple directions.
the mobility bonus decreases that more you move away from the starting square.
Ah, OK, I misunderstood that. Indeed, when you add a bonus for each target square encountered in a ray-scan loop, you could lower the bonus after the first iteration.
Such looping makes mobility quite expensive to calculate, though. In a bitboard design you could tabulate the mobility bonus directly, rather than feed the tabulated attack sets to popcnt. That would give you ultimate flexibility for how to score the various numbers of moves in the various directions. With mailbox I prefer to keep track of mobility incrementally. (Most pieces keep excatly the same mobility after a move, and it seems wasteful to determine their mobility with slow loops over and over again...) To get flexible scoring you can incrementally keep track of the number of moves they have, and whenever that changes, use it in a small lookup table to get the new bonus (after subtracting the old bonus, which you also keep track of). If you want to give an extra penalty when the piece can only move in one dimension, and has no moves orthogonal to it, you could incrementally update a linear combination of the moves in different dimension (rather than just their sum), like 7*vertical + horizontal for a Rook. And use that to index a somewhat larger table with scores.
how do you update mobility incrementally? you can do it from move generation but you still have to calculate the mobility of the other side when evaluating the whole position
your methods don't account for rook/queen batteries or x-ray attacks though, in my board state i maintain flags for pieces and colors so i could have a filter flag when sliding to a direction but this would require at least 2 branches because my own rook still has my own color flag and thus stops the scanning.
the downside of these piece flags is that i can't use them for indexing (they are too big) and i have to recur to the fruit madness of converting them to other flags.
You can maintain a table that holds the current mobility of every slider on the board. When the piece gets captured you can then subtract its mobility from the total mobility to update the latter. You can calculate the mobility in the new location of the moved piece as a side effect of generating its moves from there (i.e just count those, by popcnt on a bitboard, or by seeing how many moves were added to the move list). In addition you have to adjust the mobility of the sliders that were attacking the from-square, as these gain some moves by discovery. Each change there should also be applied to the total mobility. (With the proper sign, depending on who owns the piece.) On a capture that is all. In the rare case of a non-capture you would also have to adjust the mobility of the sliders attacking the to-square, as these now lose moves by blocking. The point is that there aren't very many sliders attacking a square, on average; IIRC it was less than one.
hgm wrote: ↑Fri Feb 18, 2022 6:39 pm
You can maintain a table that holds the current mobility of every slider on the board. When the piece gets captured you can then subtract its mobility from the total mobility to update the latter. You can calculate the mobility in the new location of the moved piece as a side effect of generating its moves from there (i.e just count those, by popcnt on a bitboard, or by seeing how many moves were added to the move list). In addition you have to adjust the mobility of the sliders that were attacking the from-square, as these gain some moves by discovery. Each change there should also be applied to the total mobility. (With the proper sign, depending on who owns the piece.) On a capture that is all. In the rare case of a non-capture you would also have to adjust the mobility of the sliders attacking the to-square, as these now lose moves by blocking. The point is that there aren't very many sliders attacking a square, on average; IIRC it was less than one.
i like this idea, i will definitely try it.
but one thing got me wondering, how should i handle pinned pieces?
this is probably subjective but i'd like to know how others do it
I guess you could include a pin penalty in the evaluation. You could make the penalty dependent on the mobility of the piece, if you want. I wouldn't consider it in the mobility term. Of the moves you count towards mobility there will always be many moves that are immediately losing.
