Kyoto Shogi (Sjaak?)

[Dann Corbit]

Well, / and % are 'infinitely slow' even on modern hardware, and using a single % operation per node slowed down Crafty by ~33%.

Are you really sure? Yes, I know that / and % are slower than *, but 33% overall slowdown sounds ridiculous.

I have seen compilers take modulus operation and turn it into a shift or an AND operation with optimization on high level for some special cases.

I suspect that the lldiv function must have been used to get that kind of a slowdown. I have seen awful performance for lldiv.

Q:\>type mod.asm

Code: Select all

; Listing generated by Microsoft (R) Optimizing Compiler Version 18.00.40629.0

include listing.inc

INCLUDELIB LIBCMT
INCLUDELIB OLDNAMES

PUBLIC  remainder
; Function compile flags: /Ogtpy
; File q:\mod.c
_TEXT   SEGMENT
val$ = 8
remainder PROC

; 4    :    return val / 262144;

        shr     rcx, 18
        mov     rax, rcx

; 5    : }

        ret     0
remainder ENDP
_TEXT   ENDS
END

Q:\>type mod.c

Code: Select all

unsigned long long remainder(unsigned long long val)
{
   return val / 262144;
}

[hgm]

Well, division or modulo by a constant known at compile time is easy: the compiler turns it into a multiplication with the inverse, and calculates the latter at compile time. For integers there of course isn't a true inverse (they would all be fractions smaller than one), but it can calculate (1<<32)/N, and by multiplying M with that get N*M<<32. It the can use the high-order 32-bit word of that. (Integer multiply instructions typically produce a result with double the normal umber of bits, appearing in a pair of register.)

If you can do integer division, you can do modulo:

A % B = A - (A/B)*B

So that takes an extra multiplication and subtraction, still much faster than a true division.

Of course division by a (known) power of two is just a shift, and a modulo by it just an AND.

I don't think such tricks are available if B is not known at compile time.

[Evert]

Back on-topic, I have a 1.5.0 release candidate that hopefully fixes the Windows problems I was having. It includes Kyoto Shogi.

Windows builds are here: http://www.eglebbk.dds.nl/program/downl ... RC-win.zip
Source: http://www.eglebbk.dds.nl/program/downl ... src.tar.gz

[GregNeto]

Evert:
Thanks!
First Impression: It works !
Seems there is "only" needed a winboard version which can handle an optional promotion on drops (if captured pieces are added to the hand in their unpromotet state).

One question: does sjaak value the pieces acoording to their mobility when there are no values or a pst defined? Has a pawn or lance on the last rank or a knight on the last two ranks zero value? I seem to remember that you mentioned an optional configurable pst somewhere but could not find it ...

HG:
I will toy around with different board representations. Sorry for another beginner question: Wouldn't on a pure 5x5 board (sq+3) >> 3 and (sq+3) & 7 a pragmatic solution?

[hgm]

Well, the upper-right corner would have number 24 in 5x5, and (24+3)>>3 = 27 / 8 = 3, while (24+3) & 7 = (16 + 8 + 3) & 7 = 3. So it give (3,3), while I think the file and rank numbers should be (4,4)...

As to WinBoard, I am still leaning to the idea of somehow making WinBoard aware that promotion is automatic, by allowing an engine to separately define promoting and non-promoting moves for each piece. When a move with a piece than would only be pseudo-legal for a promotion, and not for a deferral, the promotion is implied, and would not need any promotion suffix. In Kyoto Shogi then all moves could be defined as promotion moves (with no normal moves). In micro-Shogi all promoting move could be defined as capture-only, all non-promoting moves as non-capture only.

There should also be a provision for promotion on dropping, but this could be done by explicitly indicating drops in the piece's move discriptors. The XBetza format already defines a '@' atom for indicating drops, but currently WinBoard ignores that. By including the @ atom in the descriptor of promoting moves WinBoard could know that the piece can be dropped both ways. (For pieces that do not specify separate promoting and non-promoting moves the default interpretation would be that drops would not allow promotion.)

There are notation issues for these drop promotions as well, which require enhancement of the move parser and SAN generator. I suppose whe would want to indicate all piece types by a letter, rather than using a + prefix to indicate one type as a promoted version of the other. So when L promotes to T, and we drop the T, we want to write T@a3, and not L@a3+.

Well, don't hold your breath for any of this. I am first going to finish a first version of my Tenjiku Shogi engine.

[GregNeto]

uups, my mother always said "first think and then talk"