Static Exchange Evaluation without bitboards
Moderators: hgm, Rebel, chrisw
-
jmcd
- Posts: 58
- Joined: Wed Mar 18, 2020 10:00 pm
- Full name: Jonathan McDermid
Static Exchange Evaluation without bitboards
I've recently discovered that the SEE function I had written a few years ago was ineffective because it didnt account for x-ray attackers. Is it worth it to write a SEE function if your engine doesnt use bitboards, and are there any examples of engines that have effective SEE without bitboards?
Clovis GitHub
-
gaard
- Posts: 447
- Joined: Mon Jun 07, 2010 3:13 am
- Location: Holland, MI
- Full name: Martin W
Re: Static Exchange Evaluation without bitboards
I think the reasons for doing SEE are the same regardless of board structure. Fruit is a mailbox engine that does SEE and x-rays with hidden pieces.jmcd wrote: ↑Sat Oct 23, 2021 1:31 am I've recently discovered that the SEE function I had written a few years ago was ineffective because it didnt account for x-ray attackers. Is it worth it to write a SEE function if your engine doesnt use bitboards, and are there any examples of engines that have effective SEE without bitboards?
-
diep
- Posts: 1822
- Joined: Thu Mar 09, 2006 11:54 pm
- Location: The Netherlands
Re: Static Exchange Evaluation without bitboards
Bitboards have nothing to do with all this.
In diep i use historically incremental attacktables. Please realize this is SLOW. Sure i managed to speed it up by doing it incremental in the makemove and unmakemove but that's tough code to write. Only interesting if you write a real huge evaluation function. Xray is very easy then to have.
You do not even notice it. As the piece you read from the board determines via a table whether you scan further anyway.
The quality of the code in itself has nothing to do with what sort of datastructure you use. For each datastructure implementation works different.
With bitboards you wouldn't do attacktables incremental for example.
Another issue might be speedwise - how effective can you use those 4 AVX units the cpu's have nowadays?
Trivially my old diep that still used back then 'int' everywhere. So i just standardized upon 'int' in C code everywhere to avoid bugs by means of signed versus unsigned problems. Trying to code easier without bugs. Yet that's very slow too nowadays.
So the pain basically is that cryptic programming results in faster code - yet how do you write good chessknowledge then?
The quality of the code around qsearch - no matter how you implement is - it is total critical.
In Diep i'm also doing giving checks - but not all - very few in fact. Only when you guess it could influence the outcome of the board position a lot (like winning a piece with a fork for example or when the king is in bad position - so it's not alfa nor beta dependant). A very good quiescencesearch is total crucial to have.
Just around when i stopped developing diep - this was end december 2012 - not too long before that i had figured out that my quiescencesearch code which dated back from the 1990s - back then probably one of the best qsearches on the planet done by any engine - that it was getting outdated by 21th century standards. Doing a few checks extra now - in short 'wasting' nodes might be worth it todays knowing how thin last few plies might get searched quickly resulting in going to the quiescencesearch. Also you detect perpetual checks quicker then. So it's critical to invest lots of time here to do things better. Even if that loses massive system time. Pays itself back.
In diep i use historically incremental attacktables. Please realize this is SLOW. Sure i managed to speed it up by doing it incremental in the makemove and unmakemove but that's tough code to write. Only interesting if you write a real huge evaluation function. Xray is very easy then to have.
You do not even notice it. As the piece you read from the board determines via a table whether you scan further anyway.
The quality of the code in itself has nothing to do with what sort of datastructure you use. For each datastructure implementation works different.
With bitboards you wouldn't do attacktables incremental for example.
Another issue might be speedwise - how effective can you use those 4 AVX units the cpu's have nowadays?
Trivially my old diep that still used back then 'int' everywhere. So i just standardized upon 'int' in C code everywhere to avoid bugs by means of signed versus unsigned problems. Trying to code easier without bugs. Yet that's very slow too nowadays.
So the pain basically is that cryptic programming results in faster code - yet how do you write good chessknowledge then?
The quality of the code around qsearch - no matter how you implement is - it is total critical.
In Diep i'm also doing giving checks - but not all - very few in fact. Only when you guess it could influence the outcome of the board position a lot (like winning a piece with a fork for example or when the king is in bad position - so it's not alfa nor beta dependant). A very good quiescencesearch is total crucial to have.
Just around when i stopped developing diep - this was end december 2012 - not too long before that i had figured out that my quiescencesearch code which dated back from the 1990s - back then probably one of the best qsearches on the planet done by any engine - that it was getting outdated by 21th century standards. Doing a few checks extra now - in short 'wasting' nodes might be worth it todays knowing how thin last few plies might get searched quickly resulting in going to the quiescencesearch. Also you detect perpetual checks quicker then. So it's critical to invest lots of time here to do things better. Even if that loses massive system time. Pays itself back.