Not so long ago there was - and recently still is - a discussion here about the usefulness of the good old history table which nowadays - at such big search depths - doesn't produce reliable data for move ordering any longer just "random noise". Even Prof. Hyatt mentioned that he entirely got rid of it.
I would like to share with you my simple idea, I don't remember if it was mentioned earlier.
Let's collect and use the history data only on the first few plys like in the good old days ! This changes the formula a bit:
This way we can(? ) improve move ordering closer to the root while we can still use other methods elsewhere. I use MAXHISTORYPLY=10 value in my engine together with aging.
At least this is better than a pseudo contest I agree that is a simple proof that if it worked in the 70s it should word now too. Use it to the same depth that engines of the 70s used history successfully for, so 10 is a good guess.
if (ply < MAXHISTORYPLY && value >= beta)
{
historytable[piece][to] += (MAXHISTORYPLY - ply) * (MAXHISTORYPLY - ply);
}
Although you are correct that he should have used &&, I believe the code with a single & will work in every situation. The operator precedence for & and && is similar, so the expression is grouped the same way. The operator < on the left will evaluate to true or false, and so will the operator >= on the right. In order to apply operator & to those values, they will be converted to int, as 1 or 0. Then the bitwise operator & will do the right thing.
if (ply < MAXHISTORYPLY && value >= beta)
{
historytable[piece][to] += (MAXHISTORYPLY - ply) * (MAXHISTORYPLY - ply);
}
Although you are correct that he should have used &&, I believe the code with a single & will work in every situation. The operator precedence for & and && is similar, so the expression is grouped the same way. The operator < on the left will evaluate to true or false, and so will the operator >= on the right. In order to apply operator & to those values, they will be converted to int, as 1 or 0. Then the bitwise operator & will do the right thing.
Now I'm very careful with C operators. Mistying a '&&' into a '&', or making wrong assumptions about operator precednece and default associativity, has cost me quite a few hours of debugging already.
Recent versions of GCC will warn you if you are using a priority or associativity of operators in an 'unusual way', basically telling you: ' are you sure that's what you want to do?' (sometimes it is, but most often it's a mistake, it's really helped me quite a few times).
Theory and practice sometimes clash. And when that happens, theory loses. Every single time.
lucasart wrote:Recent versions of GCC will warn you if you are using a priority or associativity of operators in an 'unusual way', basically telling you: ' are you sure that's what you want to do?' (sometimes it is, but most often it's a mistake, it's really helped me quite a few times).
It also doesn't hurt to compile your code with clang just to see what warnings you get. It recently helped me to find a && in my code that really should have been a &.
lucasart wrote:Recent versions of GCC will warn you if you are using a priority or associativity of operators in an 'unusual way', basically telling you: ' are you sure that's what you want to do?' (sometimes it is, but most often it's a mistake, it's really helped me quite a few times).
It also doesn't hurt to compile your code with clang just to see what warnings you get. It recently helped me to find a && in my code that really should have been a &.
I know. That's how I spotted a bug recently, and fixing it gained a few elo I was doing something like this
lucasart wrote:Now I'm very careful with C operators. Mistying a '&&' into a '&', or making wrong assumptions about operator precednece and default associativity, has cost me quite a few hours of debugging already.
I use & and | in stead of && and || quite often. This can save you branches, and branches that are not there can also not be mispredicted.
And when I wrote that I thought that & had a higher priority than <.
That was also wrong. We learn: Just use a lot of () and be careful with & in conditions.
! This changes the formula a bit:
