Strange results after change in positional representation

[Fguy64]

So do you use the stored info for moved piece and captured piece for subsequent move ordering calculations then?

I would be surprised if not. As far as I know, Crafty uses MVV/LVA to order captures and this information is useful to do so.

This ties in with an above comment on piece codes/ values from Bob, which I quote for convenience

...
You can do the same thing with p=1, n=2, b=3, r=4, q=5, k=6, and a small array pv[6] = {100 300 300 500 900 99999}; Then index into this array using the piece type to get the score.

In my old system, my piece codes were also piece values, which made for efficient calculation of material balance and MVV/LVA sorting. But this has limitations, so I am looking at storing piece symbols in my position, and of course also an efficient way of looking up material values.

I like the 'small array' system quoted above. But a cornerstone of my square-centric engine is that in the position array, black pieces are negative numbers and white pieces are positive. And I use this difference to determine whether a piece is capturable as I am traversing the array. And then there is the issue of a -ve number can't be used as an array index. Other forms of lookups in java seem very slow, so I'm kind of scratching my head.

[BubbaTough]

So do you use the stored info for moved piece and captured piece for subsequent move ordering calculations then?

I would be surprised if not. As far as I know, Crafty uses MVV/LVA to order captures and this information is useful to do so.

This ties in with an above comment on piece codes/ values from Bob, which I quote for convenience

...
You can do the same thing with p=1, n=2, b=3, r=4, q=5, k=6, and a small array pv[6] = {100 300 300 500 900 99999}; Then index into this array using the piece type to get the score.

In my old system, my piece codes were also piece values, which made for efficient calculation of material balance and MVV/LVA sorting. But this has limitations, so I am looking at storing piece symbols in my position, and of course also an efficient way of looking up material values.

I like the 'small array' system quoted above. But a cornerstone of my square-centric engine is that in the position array, black pieces are negative numbers and white pieces are positive. And I use this difference to determine whether a piece is capturable as I am traversing the array. And then there is the issue of a -ve number can't be used as an array index. Other forms of lookups in java seem very slow, so I'm kind of scratching my head.

Here is one kind of silly way
#define WHITE 0
#define BLACK 1
sign[2] = {1,-1}

pieceVal = pv[piece_type] * sign[color];

[Fguy64]

So do you use the stored info for moved piece and captured piece for subsequent move ordering calculations then?

I would be surprised if not. As far as I know, Crafty uses MVV/LVA to order captures and this information is useful to do so.

This ties in with an above comment on piece codes/ values from Bob, which I quote for convenience

...
You can do the same thing with p=1, n=2, b=3, r=4, q=5, k=6, and a small array pv[6] = {100 300 300 500 900 99999}; Then index into this array using the piece type to get the score.

In my old system, my piece codes were also piece values, which made for efficient calculation of material balance and MVV/LVA sorting. But this has limitations, so I am looking at storing piece symbols in my position, and of course also an efficient way of looking up material values.

I like the 'small array' system quoted above. But a cornerstone of my square-centric engine is that in the position array, black pieces are negative numbers and white pieces are positive. And I use this difference to determine whether a piece is capturable as I am traversing the array. And then there is the issue of a -ve number can't be used as an array index. Other forms of lookups in java seem very slow, so I'm kind of scratching my head.

Here is one kind of silly way
#define WHITE 0
#define BLACK 1
sign[2] = {1,-1}

pieceVal = pv[piece_type] * sign[color];

Well, I think I see what you mean. But it kind of begs the question, no? This may be silly but it's non-trivial, at least for me. In my java program, Everything about my position is stored in an array of integers (piece symbols) that represents color by virtue of the sign of the integer. I have no piece objects, no enums, no piece lists. If I change my basic piece represntation, I may as well start over from scratch.

[Fguy64]

ok Sam, not to worry, I have a few ideas which should resolve this nicely. Thanks for the suggestion

[jwes]

So do you use the stored info for moved piece and captured piece for subsequent move ordering calculations then?

I would be surprised if not. As far as I know, Crafty uses MVV/LVA to order captures and this information is useful to do so.

This ties in with an above comment on piece codes/ values from Bob, which I quote for convenience

...
You can do the same thing with p=1, n=2, b=3, r=4, q=5, k=6, and a small array pv[6] = {100 300 300 500 900 99999}; Then index into this array using the piece type to get the score.

In my old system, my piece codes were also piece values, which made for efficient calculation of material balance and MVV/LVA sorting. But this has limitations, so I am looking at storing piece symbols in my position, and of course also an efficient way of looking up material values.

I like the 'small array' system quoted above. But a cornerstone of my square-centric engine is that in the position array, black pieces are negative numbers and white pieces are positive. And I use this difference to determine whether a piece is capturable as I am traversing the array. And then there is the issue of a -ve number can't be used as an array index. Other forms of lookups in java seem very slow, so I'm kind of scratching my head.

You can use p+6 as an array index. This make all indices >=0 assuming that -6 <=p <=6.

[Fguy64]

So do you use the stored info for moved piece and captured piece for subsequent move ordering calculations then?

I would be surprised if not. As far as I know, Crafty uses MVV/LVA to order captures and this information is useful to do so.

This ties in with an above comment on piece codes/ values from Bob, which I quote for convenience

...
You can do the same thing with p=1, n=2, b=3, r=4, q=5, k=6, and a small array pv[6] = {100 300 300 500 900 99999}; Then index into this array using the piece type to get the score.

In my old system, my piece codes were also piece values, which made for efficient calculation of material balance and MVV/LVA sorting. But this has limitations, so I am looking at storing piece symbols in my position, and of course also an efficient way of looking up material values.

I like the 'small array' system quoted above. But a cornerstone of my square-centric engine is that in the position array, black pieces are negative numbers and white pieces are positive. And I use this difference to determine whether a piece is capturable as I am traversing the array. And then there is the issue of a -ve number can't be used as an array index. Other forms of lookups in java seem very slow, so I'm kind of scratching my head.

You can use p+6 as an array index. This make all indices >=0 assuming that -6 <=p <=6.

Right, that's sort of what I ended up pressing ahead with.

piece symbols are 1-6 for white, 7-12 for black. 0 for an empty square, and -1 for the border squares on my 10x10 board. So I can use piece symbols as array indexes for looking up material values. I suppose the only drawback is that Black has to do slightly more work in moveGen to determine if a non-zero square contains a capturable piece. But I can live with that.

So for storage in movegen, src and dest squares are 7 bits each, and promo piece, captured piece, and capturing piece use 4 bits each, for a total of 26 bits. So I'm not actually storing a MVV/LVA sort key, which means I'll have to write my own sort routine instead of relying on built in java methods for sorting.

Anyways, i'm sure it's not the best system, but it's not bad for this rookie.