displaying the PV

[lucasart]

One more tiny thing, your loop terminates by "i < MAX_PLY - 1" but I think you can go one entry further, terminating by "i < MAX_PLY" instead since you do not access your pv[] array with index "i + 1". Here I assume that pv[] is defined with size MAX_PLY.

You're right, I was confusing the lines and rowsin my array..
But in the end, where is the PV ? is it

si[0].pv[0,1,2,...]

or is it the diagonal ?

[OliverUwira]

It's si[0].pv[0....n]

[lucasart]

It's si[0].pv[0....n]

Ah, that's why ! Sorry, my mistake, I thought your solution didn#t work, but I was simply using the wrong result, as I was showing the diagonal

Thank you for the precision!

[OliverUwira]

Never mind

I also got quite some help from people here.

By the way, it is interesting to note that if you in fact take the diagonal, the result will be exactly the same that your initial approach produces (-:

[Sven]

Not correct IMO, part of the deeper PV parts can be old if you do not always reach the horizon in full width search.

EDIT: Also the termination check (null entry) may become ambiguous. So you always have to copy from (d+1) to (d).

Sven

[lucasart]

Not correct IMO, part of the deeper PV parts can be old if you do not always reach the horizon in full width search.

EDIT: Also the termination check (null entry) may become ambiguous. So you always have to copy from (d+1) to (d).

Sven

It is correct, because my pv array is initialized with NoMove values before every root search.

[lucasart]

By the way, it is interesting to note that if you in fact take the diagonal, the result will be exactly the same that your initial approach produces (-:

Yes, I also noticed that

[Sven]

Not correct IMO, part of the deeper PV parts can be old if you do not always reach the horizon in full width search.

EDIT: Also the termination check (null entry) may become ambiguous. So you always have to copy from (d+1) to (d).

Sven

It is correct, because my pv array is initialized with NoMove values before every root search.

I don't think so. If your statement were right then copying the PV from (d+1) to (d) would even be redundant.

Consider this "silly" example:
After 1. e4 e5 Nf3:

Code: Select all

e4 e5 Nf3 NoMove
** e5 Nf3 NoMove
** ** Nf3 NoMove

Now you analyze 1.d4 Nf6 and stop after Nf6, i.e. you do not descend further. Now your array contains:

Code: Select all

d4 Nf6 NoMove
** Nf6 NoMove
** *** Nf3 NoMove

so you would print "d4 Nf6 Nf3" as PV with your method.

Sven

[lucasart]

Consider this "silly" example:
After 1. e4 e5 Nf3:

Code: Select all

e4 e5 Nf3 NoMove
** e5 Nf3 NoMove
** ** Nf3 NoMove

Now you analyze 1.d4 Nf6 and stop after Nf6, i.e. you do not descend further. Now your array contains:

Code: Select all

d4 Nf6 NoMove
** Nf6 NoMove
** *** Nf3 NoMove

so you would print "d4 Nf6 Nf3" as PV with your method.

Sven

No the pv shown at the root is the first line, which is simply: d4 Nf6 (and stop because NoMove). In practice it seems to work perfectly and Kurt uses it with no problems.

Displaying the *diagonal* however is incorrect, as we've seen in earlier posts. That was my mistake at the beginning.

Another thing to be noted, I always display a full PV line (exactly d moves if searching at depth = d), because at PV nodes, I do not prune with the TTable, but only use it for move ordering. It also avoid errors when considering 3/50 move draws and some mate situations.

[Sven]

Consider this "silly" example:
After 1. e4 e5 Nf3:

Code: Select all

e4 e5 Nf3 NoMove
** e5 Nf3 NoMove
** ** Nf3 NoMove

Now you analyze 1.d4 Nf6 and stop after Nf6, i.e. you do not descend further. Now your array contains:

Code: Select all

d4 Nf6 NoMove
** Nf6 NoMove
** *** Nf3 NoMove

so you would print "d4 Nf6 Nf3" as PV with your method.

Sven

No the pv shown at the root is the first line, which is simply: d4 Nf6 (and stop because NoMove). In practice it seems to work perfectly and Kurt uses it with no problems.

Displaying the *diagonal* however is incorrect, as we've seen in earlier posts. That was my mistake at the beginning.

Another thing to be noted, I always display a full PV line (exactly d moves if searching at depth = d), because at PV nodes, I do not prune with the TTable, but only use it for move ordering. It also avoid errors when considering 3/50 move draws and some mate situations.

It seems I misunderstood Oliver when I replied to his comment about using the diagonal, and maybe also you misunderstood my post in turn. But now we are in line again, knowing that displaying the diagonal is wrong and displaying pv[0] is right

Sven