how to continue

[j.t.]

i want to do this because it would actually simplify my code. i do not need a make/unmake functions (i realized i can write a custom functor for special moves like enpassant or castling), i also do not need a way to represent/store moves.
i kinda want to try this but move ordering bothers me.

If you want to do it, and it fits well into your program, do it. Though, I would guess that at some point you'll need to store moves (like for the bestmove in TT entries). I am not sure that I correctly understand what you want to do (maybe some pseudo-code could help), but so far I am not really convinced that it's simpler to use a functor instead of just generating a move list.

[tcusr]

Though, I would guess that at some point you'll need to store moves (like for the bestmove in TT entries)

exactly.
this general code works for all pieces, i just wrote this so there may be be errors

Code: Select all

template<int Piece, int Color, typename Func>
void genPieceCaptures(const Board& board, Func&& func)
{
	auto pieceBitboard = getPieceBitboard(board, Piece, Color);
	
	for (; pieceBitboard; pieceBitboard &= pieceBitboard - 1) {
		auto from = lsb(pieceBitboard);
		auto attacks = getAttacks<Piece>(from, getBlockers(board)) & getEnemies(board, Color); // for quiet: getEmpty(board)
		
		for (; attacks; attacks &= attacks - 1) {
			// apply the move, different for other kind of moves (it should be passed as argument, this is an example)
			board.allPieces[Piece] ^= 1ull << from | (attacks & -attacks); // or 1ull << bsf(attacks)
		    board.allColors[Color] ^= 1ull << from | (attacks & -attacks);
			// take care of captured piece

			if (!inCheck(board))
				func(board);

			// unmake
			board.allPieces[Piece] ^= 1ull << from | (attacks & -attacks); // or 1ull << bsf(attacks)
		    board.allColors[Color] ^= 1ull << from | (attacks & -attacks);
			// add captured piece
		}
	}
}

[mvanthoor]

Adding more evaluation terms like passed pawns would probably help improve the eval. No doubt about it. But that's some very specific concept ...

I was thinking about evaluation yesterday.

Many engines encode "rooks on half-open files = X bonus, rooks on open files = Y bonus." However, when you have mobility, which is one of the things I'd like to do just after tuning and null move, I feel having the "rooks on (half)open files" is unnecessary. A rook on F1 behind the F2 pawn is less mobile than a rook on e1 behind the e5 pawn, which is less mobile than a rook on a fully open file. So, the rooks should move to the (half)open files naturally.

Except, for the fact that a rook on e1 behind an e2 bishop is NOT more mobile (vertically) than a rook on f1 behind the f2 pawn, but it COULD be on a (half)open file. Then there's the question: would it be useful to move the rook to the (half)open file if the bishop is still on e2? It could be, for threatening a discovered check... this would be a plus for having the term to move rooks to (half)open files: you can set up "uncover the rook"-threats, which you can't do if you move all the pieces off the files first. It could even be that the engine moves pieces off files to create mobility for the rook, even though moving those pieces could be the dumbest idea ever, for whatever reason.

[j.t.]

Many engines encode "rooks on half-open files = X bonus, rooks on open files = Y bonus." However, when you have mobility, which is one of the things I'd like to do just after tuning and null move, I feel having the "rooks on (half)open files" is unnecessary.

An important point of a rook being on a half-open file is that it attacks the enemy pawn. Which may actually preferable to being on an open file in the endgame.

In my engine, I only have a parameter for rooks on open files (nothing about half-open files). In the opening, this parameter is roughly +60 cp, in the endgame, this parameter is about -40 cp.

I think having an extra rook on (half) open file parameter additionally to mobility will help. But the best way to determine if the rook on (half) open files helps anything is to test it.

[mvanthoor]

Many engines encode "rooks on half-open files = X bonus, rooks on open files = Y bonus." However, when you have mobility, which is one of the things I'd like to do just after tuning and null move, I feel having the "rooks on (half)open files" is unnecessary.

An important point of a rook being on a half-open file is that it attacks the enemy pawn. Which may actually preferable to being on an open file in the endgame.

In my engine, I only have a parameter for rooks on open files (nothing about half-open files). In the opening, this parameter is roughly +60 cp, in the endgame, this parameter is about -40 cp.

I think having an extra rook on (half) open file parameter additionally to mobility will help. But the best way to determine if the rook on (half) open files helps anything is to test it.

I'll be adding that at some point after the tuning, and pawn-hash. Just add the mobility first, then rook on open file (for mid-game and end-game), then rook on half-open file (for mid-game and end-game again), and retune and test after each addition.