Andscacs - New version 0.72

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

xmas79
Posts: 286
Joined: Mon Jun 03, 2013 7:05 pm
Location: Italy

Re: Andscacs - New version 0.72

Post by xmas79 »

Daniel Anulliero wrote:
cdani wrote:
op12no2 wrote:Very interesting Daniel. I'm doing to have to steal not calling eval if in check... :)
Was not my idea. I found it in some engines.
Hi
Lol never thought about it too :)

Then if we're Incheck in the start of qs, we need to test if mate/stalemate before stand pat and captures right?
If not ,some captures can be illegal moves and qs become false?
Thanks for your lights and sorry for my poor english! ;-)


:wink: :wink:
when in check in qs you need to generate all the moves that allows you to escape.then,if you could not do any move that's mate. you check for stalemate only when not in check (obviously)
User avatar
cdani
Posts: 2204
Joined: Sat Jan 18, 2014 10:24 am
Location: Andorra

Re: Andscacs - New version 0.72

Post by cdani »

lucasart wrote:
cdani wrote: “Piece hash” or whatever the name is, if it exists. I did not find it anywhere. Is a hash of two moves (like killers) related to the hash of all pieces minus king and pawns. It’s just a first try and is not optimized. So in fact the key is (hash ^ pawn_hash). It has very little size to not bother other engines. I will try a lot more variations and bigger sizes. May be someone wants to try it and post his results. Seems that there is some strength to win for all the engines.
Would love to try, but I don't understand your explanation. The piece hash is the key restricted to pieces. OK. But what do you use it for?
I better put some code.

Code: Select all

//hash peces
struct hp_Entry {
	uint64_t key;
	Move move1, move2;
};

static const int hp_count = 0x20000;
hp_Entry piecehash[hp_count];

hp_Entry * hp_get(uint64_t key) 
{
	const size_t idx = key & (hp_count - 1);
	return &piecehash[idx];
}

void hp_set(uint64_t key, Move m)
{
	const size_t idx = key & (hp_count - 1);
	//as killers
	if (piecehash[idx].key == key) {
		if (piecehash[idx].move1 != m)
			piecehash[idx].move2 = piecehash[idx].move1;
	} else {
		piecehash[idx].key  = key;
		piecehash[idx].move2 = InvalidMove;
	}
	piecehash[idx].move1 = m;
}

//before start of the search
hp_Entry *hp = hp_get(hash ^ hashpawns);
	if (hp->dm_key == (hash ^ hashpawns)) {
		hp_move1 = hp->move1;
		hp_move2 = hp->move2;
	} else {
		hp_move1 = InvalidMove;
		hp_move2 = InvalidMove;
	}

//use hp_moves as you wish

//end of the search
if (bettermove) {
	hp_set(hash ^ hashpawns, bettermove);
}
User avatar
cdani
Posts: 2204
Joined: Sat Jan 18, 2014 10:24 am
Location: Andorra

Re: Andscacs - New version 0.72

Post by cdani »

For the moment I'm using the moves to sort them after the other different types of killers.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: Andscacs - New version 0.72

Post by Evert »

cdani wrote: I better put some code.

Code: Select all

//hash peces
struct hp_Entry {
	uint64_t key;
	Move move1, move2;
};

static const int hp_count = 0x20000;
hp_Entry piecehash[hp_count];

hp_Entry * hp_get(uint64_t key) 
{
	const size_t idx = key & (hp_count - 1);
	return &piecehash[idx];
}

void hp_set(uint64_t key, Move m)
{
	const size_t idx = key & (hp_count - 1);
	//as killers
	if (piecehash[idx].key == key) {
		if (piecehash[idx].move1 != m)
			piecehash[idx].move2 = piecehash[idx].move1;
	} else {
		piecehash[idx].key  = key;
		piecehash[idx].move2 = InvalidMove;
	}
	piecehash[idx].move1 = m;
}

//before start of the search
hp_Entry *hp = hp_get(hash ^ hashpawns);
	if (hp->dm_key == (hash ^ hashpawns)) {
		hp_move1 = hp->move1;
		hp_move2 = hp->move2;
	} else {
		hp_move1 = InvalidMove;
		hp_move2 = InvalidMove;
	}

//use hp_moves as you wish

//end of the search
if (bettermove) {
	hp_set(hash ^ hashpawns, bettermove);
}
Ok, so let me see if I can put the idea into words: this is a generalisation of the killer-concept that tries to take into account that a pointless move (in particular, a pawn push) does not necessarily/typically invalidate the threat posed by a killer move.

Sounds reasonable, but I'm curious to know how this compares with considering the killers from two ply earlier (which is the same sort of idea). I'd also be curious to know how this fares if you do allow for pawn pushes, but not pawn exchange/loss (which would not affect the hash key used here, but perhaps this is not something that happens often enough that it needs to be worried about).
User avatar
cdani
Posts: 2204
Joined: Sat Jan 18, 2014 10:24 am
Location: Andorra

Re: Andscacs - New version 0.72

Post by cdani »

Evert wrote: Ok, so let me see if I can put the idea into words: this is a generalisation of the killer-concept that tries to take into account that a pointless move (in particular, a pawn push) does not necessarily/typically invalidate the threat posed by a killer move.
Yes, or a king move. For example in the starting position Nf3 is good after a lot of different pawn pushes. Is to some extend like history but something more concrete of the position.
Evert wrote: Sounds reasonable, but I'm curious to know how this compares with considering the killers from two ply earlier (which is the same sort of idea). I'd also be curious to know how this fares if you do allow for pawn pushes, but not pawn exchange/loss (which would not affect the hash key used here, but perhaps this is not something that happens often enough that it needs to be worried about).
Nice to try also those ideas!