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)Daniel Anulliero wrote:Hicdani wrote:Was not my idea. I found it in some engines.op12no2 wrote:Very interesting Daniel. I'm doing to have to steal not calling eval if in check...
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!
Andscacs - New version 0.72
Moderators: hgm, Rebel, chrisw
-
- Posts: 286
- Joined: Mon Jun 03, 2013 7:05 pm
- Location: Italy
Re: Andscacs - New version 0.72
-
- Posts: 2204
- Joined: Sat Jan 18, 2014 10:24 am
- Location: Andorra
Re: Andscacs - New version 0.72
I better put some code.lucasart wrote: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?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.
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);
}
Daniel José - http://www.andscacs.com
-
- Posts: 2204
- Joined: Sat Jan 18, 2014 10:24 am
- Location: Andorra
Re: Andscacs - New version 0.72
For the moment I'm using the moves to sort them after the other different types of killers.
Daniel José - http://www.andscacs.com
-
- Posts: 2929
- Joined: Sat Jan 22, 2011 12:42 am
- Location: NL
Re: Andscacs - New version 0.72
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.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); }
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).
-
- Posts: 2204
- Joined: Sat Jan 18, 2014 10:24 am
- Location: Andorra
Re: Andscacs - New version 0.72
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: 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.
Nice to try also those ideas!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).
Daniel José - http://www.andscacs.com