Beginning hashtable question.

[Sven]

OK, point taken. Anyways, in anticipation of more advanced search techniques, I decided to try and change my scheme so that the recursion variable (draft) is decremented, and evaluate ( Q ) is called at ply (or depth or whatever you call it) equal to zero. It was easy enough to do.

"called at ply equal to zero"? You mean at draft == 0, or is "ply" now a synonym for draft??

That still leaves the question of whether to actually use array index 0, no? I guess I find it simpler to have the recursion variable (in my case ply) equal the array index, which as I see implies an array dimension of maxDepth+1. And a little unused space.

No. The +1 in array dimensions is caused by not using entry 0, which is not the same as what you wrote. Also, what you are now doing seems to imply that you fill (and read) your ply-related arrays in reverse order, from higher to lower index.



Once again: what is your "recursion variable" now: "draft" or "ply"? Or are there two different ones?

And my PV array updates look like this...

Code: Select all

if( eval > alpha ) { 
    alpha = eval;
    PV[ply][ply] = m;
    if( ply > 1 ) System.arraycopy( PV[ply-1], 1, PV[ply], 1, ply-1 );
}

Note that this block does not include the hashing code. I'm thinking at some point that I should be able to do away with this PV[][] array, which is a holdover from pre-hashing days and strictly for display, and get any information I need directly from the hash table.

What is "ply" in this context? Distance to root + 1, or "draft"? Your code looks suspicious to me, can you explain what is copied from where to where?

EDIT: from the Java reference I can see what System.arraycopy() does in this case. You copy the contents of PV[ply-1][1] .. PV[ply-1][ply-1] to PV[ply][1] .. PV[ply][ply-1]. So my last question is solved ...

Sven

[Fguy64]

OK, point taken. Anyways, in anticipation of more advanced search techniques, I decided to try and change my scheme so that the recursion variable (draft) is decremented, and evaluate ( Q ) is called at ply (or depth or whatever you call it) equal to zero. It was easy enough to do.

"called at ply equal to zero"? You mean at draft == 0, or is "ply" now a synonym for draft??

That still leaves the question of whether to actually use array index 0, no? I guess I find it simpler to have the recursion variable (in my case ply) equal the array index, which as I see implies an array dimension of maxDepth+1. And a little unused space.

No. The +1 in array dimensions is caused by not using entry 0, which is not the same as what you wrote. Also, what you are now doing seems to imply that you fill (and read) your ply-related arrays in reverse order, from higher to lower index.



Once again: what is your "recursion variable" now: "draft" or "ply"? Or are there two different ones?

And my PV array updates look like this...

Code: Select all

if( eval > alpha ) { 
    alpha = eval;
    PV[ply][ply] = m;
    if( ply > 1 ) System.arraycopy( PV[ply-1], 1, PV[ply], 1, ply-1 );
}

Note that this block does not include the hashing code. I'm thinking at some point that I should be able to do away with this PV[][] array, which is a holdover from pre-hashing days and strictly for display, and get any information I need directly from the hash table.

What is "ply" in this context? Distance to root + 1, or "draft"? Your code looks suspicious to me, can you explain what is copied from where to where?

Sven

think of ply as just the name I use for the recursion variable. I suppose it is remaining search depth. when ply=0, evaluate() is called. That should make its meaning clear. After the code is executed, PV[ply] is a one dimensional array representing the PV from that node after the alpha update. PV[ply][ply] is the first move, PV[ply][1] is the last move.

Anyways, the code works. Even if people don't like my terminology.

[Fguy64]

anyways, I'm starting to sense limitations to this also. I like to use my recursion variable directly as an array index, but I suppose that will cause problems also. I guess, as was suggested earlier, I really will eventually need to maintain a second variable as a PV array index. May as well get started now.

[Sven]

OK, point taken. Anyways, in anticipation of more advanced search techniques, I decided to try and change my scheme so that the recursion variable (draft) is decremented, and evaluate ( Q ) is called at ply (or depth or whatever you call it) equal to zero. It was easy enough to do.

"called at ply equal to zero"? You mean at draft == 0, or is "ply" now a synonym for draft??

That still leaves the question of whether to actually use array index 0, no? I guess I find it simpler to have the recursion variable (in my case ply) equal the array index, which as I see implies an array dimension of maxDepth+1. And a little unused space.

No. The +1 in array dimensions is caused by not using entry 0, which is not the same as what you wrote. Also, what you are now doing seems to imply that you fill (and read) your ply-related arrays in reverse order, from higher to lower index.



Once again: what is your "recursion variable" now: "draft" or "ply"? Or are there two different ones?

And my PV array updates look like this...

Code: Select all

if( eval > alpha ) { 
    alpha = eval;
    PV[ply][ply] = m;
    if( ply > 1 ) System.arraycopy( PV[ply-1], 1, PV[ply], 1, ply-1 );
}

Note that this block does not include the hashing code. I'm thinking at some point that I should be able to do away with this PV[][] array, which is a holdover from pre-hashing days and strictly for display, and get any information I need directly from the hash table.

What is "ply" in this context? Distance to root + 1, or "draft"? Your code looks suspicious to me, can you explain what is copied from where to where?

Sven

think of ply as just the name I use for the recursion variable. I suppose it is remaining search depth. when ply=0, evaluate() is called. That should make its meaning clear. After the code is executed, PV[ply] is a one dimensional array representing the PV from that node after the alpha update. PV[ply][ply] is the first move, PV[ply][1] is the last move.

Anyways, the code works. Even if people don't like my terminology.

It may work today but will be broken soon.

Code: Select all

  0 1 2 3 4 5 6
0 * * * * * * *
1 * x - - - - -
2 * x x - - - -
3 * x x x - - -
4 * x x x x - -
5 * x x x x x -
6 * O O O O O O

So in my example above showing your triangular implementation for iteration no. 6, your PV at the root is in the line numbered with 6, containing upper case O letters. You start at the bottom and go up, and variations are to be read from right to left. PV update is done by copying the appropriate part of a line into the line below it. Understood.

Do you now see that there is no room for any kind of search extension? You would not even be able to ever implement check extension with this approach.

But if you insist ...

Sven

[Sven]

anyways, I'm starting to sense limitations to this also. I like to use my recursion variable directly as an array index, but I suppose that will cause problems also. I guess, as was suggested earlier, I really will eventually need to maintain a second variable as a PV array index. May as well get started now.

Good idea

Sven