TogaII bug

[borko]

It seems there is bug in TogaII.

File pawn.cpp line 525

Code: Select all

rank = BIT_LAST(board->pawn_file[me][file]);

fix:

Code: Select all

if(me == White) rank = BIT_LAST(board->pawn_file[me][file]);
else rank = BIT_FIRST(BitRev[board->pawn_file[me][file]]);

Regards,
Borko

[Karlo Bala]

It seems there is bug in TogaII.

File pawn.cpp line 525

Code: Select all

rank = BIT_LAST(board->pawn_file[me][file]);

fix:

Code: Select all

if(me == White) rank = BIT_LAST(board->pawn_file[me][file]);
else rank = BIT_FIRST(BitRev[board->pawn_file[me][file]]);

Regards,
Borko

I think that:

Code: Select all

BIT_LAST(board->pawn_file[me][file] == BIT_FIRST(BitRev[board->pawn_file[me][file]]

[borko]

I think you find the same pawn but rank is different.

Borko

[Tony]

I think you find the same pawn but rank is different.

Borko

Not if you change bitfirst to bitlast AND do a bitreverse.

Your idea seems correct but since you correct it double, it gives exactly the same as before.

Tony

[Sven]

I think you find the same pawn but rank is different.

Borko

Not if you change bitfirst to bitlast AND do a bitreverse.

Your idea seems correct but since you correct it double, it gives exactly the same as before.

Tony

I would like to say how I understand the code.

Code: Select all

board->pawn_file[me][file]

shows presence of pawns on ranks of a given file relative to a given color 'me', so for white and rank 2 the same bit is used as for black and rank 7. (Edit: Actually the numbers for 'rank 2' and 'rank 7' may be different from 2 and 7 but this is an implementation detail.) 'pawn_file' has some bits set between bit positions p and q (as widest possible range), where p < q (in this case p=4 and q=11, I think, but it should not matter).

AFAIK (from Fruit 2.1 code - correct me if this has changed in Toga), BIT_FIRST(pf) returns the smallest position x of all set bits in the argument pf (x >= p), and BIT_LAST(pf) returns the greatest position y of all set bits in pf (y <= q).

BitRev[pf] reverts the color viewpoint, it has bits set between bit positions K-q and K-p, with K as total number of "pseudo" ranks minus 1 (here K=15 but again this should not matter). The smallest positions of set bits are closer to K-q and the greatest ones closer to K-p.

BIT_FIRST(BitRev[pf]) therefore returns K-y IMHO. I do not see why this should always be the same as y (in fact it is almost never the same). This means that Borko's idea would not work anyway. Another BitRev[] around it would be necessary:

Code: Select all

BitRev[BIT_FIRST(BitRev[pf])] == BIT_LAST(pf)
/* and also: */
BitRev[BIT_LAST(BitRev[pf])] == BIT_FIRST(pf)

but since the resulting 'rank' of the whole operation shall still be color-independent this is not necessary at all.

So unfortunately I disagree with Borko, Karlo and Tony at once But at least I agree with that part of the Toga (and Fruit 2.1) code.

Of course I may be wrong, please correct me in this case.

Sven

[borko]

Sorry, you have right.

Borko

[Karlo Bala]

I think you find the same pawn but rank is different.

Borko

Not if you change bitfirst to bitlast AND do a bitreverse.

Your idea seems correct but since you correct it double, it gives exactly the same as before.

Tony

I would like to say how I understand the code.

Code: Select all

board->pawn_file[me][file]

shows presence of pawns on ranks of a given file relative to a given color 'me', so for white and rank 2 the same bit is used as for black and rank 7. (Edit: Actually the numbers for 'rank 2' and 'rank 7' may be different from 2 and 7 but this is an implementation detail.) 'pawn_file' has some bits set between bit positions p and q (as widest possible range), where p < q (in this case p=4 and q=11, I think, but it should not matter).

AFAIK (from Fruit 2.1 code - correct me if this has changed in Toga), BIT_FIRST(pf) returns the smallest position x of all set bits in the argument pf (x >= p), and BIT_LAST(pf) returns the greatest position y of all set bits in pf (y <= q).

BitRev[pf] reverts the color viewpoint, it has bits set between bit positions K-q and K-p, with K as total number of "pseudo" ranks minus 1 (here K=15 but again this should not matter). The smallest positions of set bits are closer to K-q and the greatest ones closer to K-p.

BIT_FIRST(BitRev[pf]) therefore returns K-y IMHO. I do not see why this should always be the same as y (in fact it is almost never the same). This means that Borko's idea would not work anyway. Another BitRev[] around it would be necessary:

Code: Select all

BitRev[BIT_FIRST(BitRev[pf])] == BIT_LAST(pf)
/* and also: */
BitRev[BIT_LAST(BitRev[pf])] == BIT_FIRST(pf)

but since the resulting 'rank' of the whole operation shall still be color-independent this is not necessary at all.

So unfortunately I disagree with Borko, Karlo and Tony at once But at least I agree with that part of the Toga (and Fruit 2.1) code.

Of course I may be wrong, please correct me in this case.

Sven

Yes, you are right
Ranks are stored from white and black point of view. No we know who study fruit source carefully

[borko]

I agree with Sven. Rank is color independent, but to make proper square of selected pawn you have to change the calculated rank. For example: black pawn on square b2 gets rank 7 instead Rank 2.

Code: Select all

if(me == White) rank = BIT_LAST(board->pawn_file[me][file]);
else rank = BIT_FIRST(BitRev[board->pawn_file[me][file]]);

single_file[me] = SQUARE_MAKE(file,rank);

I hope I understand the code correctly.

Borko