Is LMR Sound.

[hgm]

No, it isn't. In normal alpha-beta terminology the beta-cutoff condition is

if(score >= beta) ...

This isn't fatal, however. It just means you won't cut as many branches as you can, and thus waste time. But it won't overlook anything.

[Henk]

No, it isn't. In normal alpha-beta terminology the beta-cutoff condition is

if(score >= beta) ...

This isn't fatal, however. It just means you won't cut as many branches as you can, and thus waste time. But it won't overlook anything.

I copied the condition (score > beta) from the book Prolog Programming for artificial intelligence by Ivan Bratko.

I changed it into score >= beta. What happened: the algorithms run slower. But again I'm going too quick now, I did not measure ELO.

[hgm]

What do you mean by 'run slower'? Nodes per second, or time to depth?

[Henk]

What do you mean by 'run slower'? Nodes per second, or time to depth?

Time to depth increased went from 11 to 17 seconds. Nodes per second was a bit better: 84834 < 86929.

If this says anything. I stop now.

[Steve Maughan]

Hi Henk,

Here's what I suggest. Create a "simple" engine which includes all of these components:

• > Piece Square Tables for evaluation
  > Quiescent Search
  > Killer moves (only quiet moves)
  > Hash table
  > Null move
  > Move ordering (hash, captures by MVV/LVA, killers, rest)

A basic implementation which includes all of these component will play at between 1900 ELO and 2100 ELO. If it doesn't then you have bugs. You'll learn a lot by doing this.

Once you have this working then you can start to ask more esoteric questions.

Steve

[Steve Maughan]

If this says anything. I stop now.

Yes - you have bugs!!

[Don]

Hi Henk,

Here's what I suggest. Create a "simple" engine which includes all of these components:

• > Piece Square Tables for evaluation
  > Quiescent Search
  > Killer moves (only quiet moves)
  > Hash table
  > Null move
  > Move ordering (hash, captures by MVV/LVA, killers, rest)

A basic implementation which includes all of these component will play at between 1900 ELO and 2100 ELO. If it doesn't then you have bugs. You'll learn a lot by doing this.

Once you have this working then you can start to ask more esoteric questions.

Steve

I would suggest he skip the hash table part - or at least do this last. If he is having trouble with other things this is going to be a bear for him.

So let me reorder the list a bit, to propose an ordering for doing this:

• > Piece Square Tables for evaluation
  > Quiescent Search
  > Killer moves (only quiet moves)
  > Move ordering (hash, captures by MVV/LVA, killers, rest)
  > Null move
  > Hash table

I would also start with the most basic possible alpha/beta search. No aspiration or PVS or anything fancy, just negamax. In this way he can build things up 1 step at a time, checking his work as he goes. For example if PVS search doesn't improve the program you are doing something wrong, If killers don't, then you are doing something wrong, etc....

[Henk]

I got the same problem when checking history ( checking whether three times same position gives a draw). That also was damaging clarity of my code.

Of course I did not remove the history check. You cannot do without
or you will violate the rules of chess.

[Henk]

(...)
My fail high condition is

if (score > upperbound)

Is that last condition ok?(...)

No the condition should be:

Code: Select all

if (score >= upperbound)

It does make a difference.

As I said you need a better understanding of the basics.

Steve

if I change the condition into score >= upperbound
other conditions must be changed too:
for instance:

score = -SelectQuiescence(depth - 100, -Value, -Value);
if (score > Value)
{
score = -SelectQuiescence(depth - 100, -ub, -lb);
}

must be changed into (score >= Value)

...

[Don]

(...)
My fail high condition is

if (score > upperbound)

Is that last condition ok?(...)

No the condition should be:

Code: Select all

if (score >= upperbound)

It does make a difference.

As I said you need a better understanding of the basics.

Steve

if I change the condition into score >= upperbound
other conditions must be changed too:
for instance:

score = -SelectQuiescence(depth - 100, -Value, -Value);
if (score > Value)
{
score = -SelectQuiescence(depth - 100, -ub, -lb);
}

must be changed into (score >= Value)

...

Yes, you must make it right.

Remember this, if the score is >= beta it's not an accurate score, it's a lower bound. The "real" score could be beta or it could be higher.

If the score is <= alpha it's also not necessarily the precise score, it's an upper bound. The "real" score could be alpha or it could be lower.

A zero width window is alpha = beta - 1 - it's zero width because there can be no integer scores between them.

If you are having issues put some asserts in your code, such as:

assert(alpha < beta);

You may or many not do the >= comparison of course depending on the context, but a fail low is alway <= alpha and a fail high is always >= beta.

You may adjust alpha for a given node during a search, in which case you might say,

if ( score > alpha ) alpha = score;

You would do that test AFTER testing for a beta cutoff:

if (score >= beta) return score;