GregNeto wrote:Still fascinated by this variant! One observation: sometimes it seems that sjaaks has crashed, but typing "go" reveals that is still searching at a low depht. This is happening when there are pieces in hand. It seems that it is lost in quiescence search. In kyoto every move is a promotion, even drops ....[/img]
That's a very good point. A move being a promotion should not be a criterion for including it in QS in this variant. I should fix that.
Thanks!
But there is something wrong in the windows console mode (or in my kyoto.txt ). Load kyoto.txt, "variant kyoto "then "analyse", then enter "Sc2B" "Kb4" and "Bb1S" and the Tokin on a1 is removed. In some other positions a King appears on a1 (sometimes replacing a Tokin) and in the hand the King is -1 ...
GregNeto wrote:But there is something wrong in the windows console mode (or in my kyoto.txt ). Load kyoto.txt, "variant kyoto "then "analyse", then enter "Sc2B" "Kb4" and "Bb1S" and the Tokin on a1 is removed.
I can confirm that this also happens in my (slightly different) version of the variant definition. Only in analysis mode though, not in force mode.
Why it happens is a mystery to me at this point though.
In some other positions a King appears on a1 (sometimes replacing a Tokin) and in the hand the King is -1 ...
Maybe I should limit the number of Kings?
No, that is the default for a royal piece. Besides, if it drops a king when it had 0 in hand, then leaving -1 kings in hand is correct.
Both these things suggest that there is a bug in decoding the moves.I'll investigate.
Evert wrote:A move being a promotion should not be a criterion for including it in QS in this variant. I should fix that.
I have now done this, it makes a considerable difference in getting consistent search depths from ply to ply (and larger depths too). I haven't done a formal test to see whether it makes any difference strength-wise, however.
This will make it into the next release. There are a few minor things that I want to get done first (and some Windows-specific issues I want to hear about).
Evert wrote:
Both these things suggest that there is a bug in decoding the moves.I'll investigate.
I found a couple of bugs by running in debug mode, and I fixed those. The problem has now gone away.
I'm not entirely happy because I don't fully understand why those bugs would cause this behaviour, so I may go back and break things again in an attempt to figure this out. For now, it seems safe to say this will be fixed in the next release.
After some playing around with sunfish in python I decided to write a kyoto shogi program in C. The foundation will be TSCP crazyhouse.
Would you recommend another board representation than mailbox 7x9 ? Also on a 5x5 board the tricks with x >> 3 and x & 7 for fast checking the rank and file of a square won't work, I can't find anything better than (sq / 5) or (sq % 5) ....
Well, / and % are 'infinitely slow' even on modern hardware, and using a single % operation per node slowed down Crafty by ~33%.
So I would recommend to make the board larger than needed, and just fill the unused squares with 'boundary guards'. When you use a 5 x 5 inner area of a 16 x 9 board you can get file and rank by sqr & 7 and sqr >> 4.
If you want to minimally change TSCP you could just keep whatever board format it has now, and fill the 3 extra files and ranks with border guards to make them inaccessible.
It is what Bob reported when he tried to allow arbitrary hash-table size an taking index = key % size. Unless my memory is failing me completely. I think a % operation takes 36 clocks, and each core has only a single divide unit. In that time you could do 144 other instructions. I guess one of the problems was that the modulo in in the same critical path has the RAM access, with a difficult-to-predict branch (hash hit or miss) after it, so that very little useful work can be done in parallel.
