It is official now: 2002 ELO with 1961 characters!

[Tony]

I do not understand it.

You say:
"x-2&M tests if the square 2 left from the FROM square x is on the board (it is non-zero, i.e. true, if it is off the board)."

Why do you need to check the square 2 left from the FROM square.

You may want to check a square that is 1 left from the from square to see if the pawn is supprted by a friendly pawn but I see no reason to check difference of 2 squares.

Uri

If you moved your G2 pawn and there is no E2 pawn then you left a hole on F3.

Tony

[hgm]

Do you use the Mingw compiler? In case you do, what version is it? Thanks

Pablo

I used gcc under cygwin. That might be the same, I am not sure.

And to Uri,

indeed, as Tony says: the penalty is for creating squares that are no longer defended or defendable by a Pawn. Without this term it tends to create such weak squares. Adding a bonus for Pawns defending each other does not solve that: it would still play e3 and g3 while there was a Pawn on f2, creating a hole on f3. If e3 is played, g3 must be suppressed, and vice versa. This proved much more important for getting viable Pawn structures than Pawns defending each other.

[Spock]

The rating has now improved to 2015 ELO after a few more games were added. There is a bit of fluctuation as we add more games; it should stabilise eventually

[Piotr Cichy]

Hello Harm,

congratulations! MicroMax improves very quickly, in a few years it probably will beat Rybka

Your code is really small, even my small engine pikoSzachy (picoChess) is giant comparing to it. Current version of piko (2.1) has the size of source code 25781 bytes, and not yet finished version 2.2 has actually 24948 bytes. This is counted with comments, whitespaces etc.

There is one difference between MicroMax and piko - You are interested in getting as small source code as possible, while I want to have executable file as small as possible.

[Uri Blass]

Hello Harm,

congratulations! MicroMax improves very quickly, in a few years it probably will beat Rybka

Your code is really small, even my small engine pikoSzachy (picoChess) is giant comparing to it. Current version of piko (2.1) has the size of source code 25781 bytes, and not yet finished version 2.2 has actually 24948 bytes. This is counted with comments, whitespaces etc.

There is one difference between MicroMax and piko - You are interested in getting as small source code as possible, while I want to have executable file as small as possible.

Note that I have no idea what is going to be the size of the exe file based on the source code so I have no idea if some change will make the exe file bigger or shorter.

I do not consider the task of making the exe file as short as possible as interesting task simply because I even have no idea how to think about it.

Uri

[Tony]

You are correct: It did not occur to me to update the explanation of variable names yet. I did not change many names, but the assignments of R and W in the old explanation were tentative, i.e. I had them reserved for making future changes that in the end did not prove (sufficiently) benificial.

R is now the game-stage indicator, starting at 0, and reaching 40 when all non-Pawn material is captured. So (R>>2) is a Pawn push bonus that increases from 0 to 10 as the game progresses. (By the way, using this term was suggested to me by Maarten Claessens.)

x-2&M tests if the square 2 left from the FROM square x is on the board (it is non-zero, i.e. true, if it is off the board).
If it is on the board, the || operator needs to evaluate its right-hand-side operand, b[x-2]-u, which is then an on-board access that compares the piece at square x-2 with the piece that moved, u. If they are the same (i.e. both Pawns, as this happens in the section that is only executed for Pawn moves, and of the same color) the expression (x-2&M||b[x-2]-u), which is parsed as ((x-2)&M) || (b[x-2]-u), evaluates to 0 (meaning no penalty), if there isn't an own pawn there, or it was off board, it evaluates to 1 (which is later multiplied by the factor 9 in front of the parantheses), and you get the penalty.

The last two lines are the 6th/7th rank bonus, which is indeed the most obfuscated part of the code:
y is the TO square, y+16 shifts it one rank, (to number ranks from 1-8, rather than 0 to 7) and (y+16)&32 then isolates the '2' bit of the binary rank number. Thus it evaluates to 32 for a TO square on rank 2,3,6 and 7, and to zero otherwise. Then it is ANDed with u, which in the '32' bit encodes if the Pawn moving now had moved before ('virgin bit'). If it had not, than the Pawn was apparently on the 2nd rank, and the current TO square thus on the 3rd rank, and the '32' bit ends up cleared. So the value of 32 only results for Pawns pushed to 6th/7th rank (if they are white; 2nd/3rd if they are black). Multiplying by 2 gives the mentioned bonus of 64.

Now y+r+1 is where you get if you would continue the current move by one more step (r) and one square to the right, and with &S (S=128) you test if this falls off the board rank-wise. If it does, the current Pawn move was a promotion, and it gets the bonus 647-p, (as specified by the conditional (y+r+1) ? ... : ... operator), where p is the piece type: 1 or 2 depending on the color of the Pawn.

So in the end V is set to 647-p (promotion), 64 (move to 6th/7th rank) or 0 (other Pawn moves).

This V is than added to i, (V+=i), which holds value of captured material, to incorporate the calculated bonus in the score of the move. In total a promotion earns 64+64+647-p = 775-p = 773 or 774, (as you always have to cross 6th and 7th rank to promote), which is approximately the difference in value of Queen and Pawn.

This V is also added to the piece code on the board b[y], so that it is increased by 64 for Pawns on the 6th, 128 for pawns on the 7th, and 775-p for 'Pawns' on the 8th. As the piece type originally was p, this means that for a Pawn on the 8th the piece type becomes 775 = 768+7. But as the board is an array of char, the 768 = 3*256 is clipped off, and only the 7 remains, which happens to be the piece type for a Queen.

For Pawns on 6th or 7th the bonus of 64 or 128 remains stored in their piece encoding on the board (in bits that were otherwise unused), so that it can be added to the piece value when the Pawn should be captured on 6th or 7th rank. In effect this makes Pawns on 6th or 7th rank distinct pieces, different from ordinary Pawns, with different piece values, (but with the same moves), to which ordinary Pawns promote if they reach 6th or 7th rank.

I like this description. It almost seems like taking advantage of mathematical coincidenties.
I was wondering, is it an idea to give a capturing piece the bonusses of the piece it captures ? It would avoid the "put the piece on the best square before I loose it". It would introduce some other bad beheavior, but I can't theorise which would be worse. Might be an idea to try.

Cheers,

Tony

[nczempin]

Hello Harm,

congratulations! MicroMax improves very quickly, in a few years it probably will beat Rybka

Your code is really small, even my small engine pikoSzachy (picoChess) is giant comparing to it. Current version of piko (2.1) has the size of source code 25781 bytes, and not yet finished version 2.2 has actually 24948 bytes. This is counted with comments, whitespaces etc.

There is one difference between MicroMax and piko - You are interested in getting as small source code as possible, while I want to have executable file as small as possible.

Note that I have no idea what is going to be the size of the exe file based on the source code so I have no idea if some change will make the exe file bigger or shorter.

I do not consider the task of making the exe file as short as possible as interesting task simply because I even have no idea how to think about it.

Uri

Can all others please also report what they don't have any idea of?
For example, I have no idea how I can write an engine that can beat Rybka.


SCNR

[nczempin]

Hello Harm,

congratulations! MicroMax improves very quickly, in a few years it probably will beat Rybka

Your code is really small, even my small engine pikoSzachy (picoChess) is giant comparing to it. Current version of piko (2.1) has the size of source code 25781 bytes, and not yet finished version 2.2 has actually 24948 bytes. This is counted with comments, whitespaces etc.

There is one difference between MicroMax and piko - You are interested in getting as small source code as possible, while I want to have executable file as small as possible.

Hi Piotr,

I'm working on some chess code (maximum of 2048 12-bit words) for a little hardware project called the XGamestation. Since my version is for the "Pico Edition", it would be very fitting to call it "PicoChess". Of course it could cause confusion with you engine. However, my version is not really an "engine", it won't run on a PC, and only about 3 people in the world will try it out. Would you mind me calling the program "PicoChess" (and of course providing a link to your engine home page in case anyone accidentally finds my program instead of PicoSzachy) under these circumstances?

[Tony Thomas]

Hello Harm,

congratulations! MicroMax improves very quickly, in a few years it probably will beat Rybka

Your code is really small, even my small engine pikoSzachy (picoChess) is giant comparing to it. Current version of piko (2.1) has the size of source code 25781 bytes, and not yet finished version 2.2 has actually 24948 bytes. This is counted with comments, whitespaces etc.

There is one difference between MicroMax and piko - You are interested in getting as small source code as possible, while I want to have executable file as small as possible.

Hi Piotr,

I'm working on some chess code (maximum of 2048 12-bit words) for a little hardware project called the XGamestation. Since my version is for the "Pico Edition", it would be very fitting to call it "PicoChess". Of course it could cause confusion with you engine. However, my version is not really an "engine", it won't run on a PC, and only about 3 people in the world will try it out. Would you mind me calling the program "PicoChess" (and of course providing a link to your engine home page in case anyone accidentally finds my program instead of PicoSzachy) under these circumstances?

Why do you have to call it Pico? Call it milli or Femto for a change.

[hgm]

I like this description. It almost seems like taking advantage of mathematical coincidenties.
I was wondering, is it an idea to give a capturing piece the bonusses of the piece it captures ? It would avoid the "put the piece on the best square before I loose it". It would introduce some other bad beheavior, but I can't theorise which would be worse. Might be an idea to try.

Yes, I try to make use of any coincidence I can. That the virgin bit in the piece encoding happened to align with the bit of the square numbering relevant for 6th/7th rank was pure luck.

After having arrived at this solution for the advanced Pawns, I indeed wonder if it wouldn't be a good idea to eliminate the table with piece values altogether, and in stead declare the board as an array of integers, and use the high-order bits to hold the piece value. On each move you could then correct this piece value for the piece-square points, so that they consistently disappear if if the piece is captured. The score of a move would than simply be the value of the piece after the move minus that before the move, plus the value of the old contents of the to-square. No exception for promotions would be necessary (but it would have to change the piece code+value, of course).

To Piotr:

I decided to take source size, rather than executable size as a measure to be more independent for the particular compiler used. For such small programs, .exe size seems often dominated by linked library routines, And my impression is that a lot of unnecessary stuff is linked. Plus that .exe sizes seem to be rounded to multiples of 512 byte, so that small progress in the right direction becomes unobservable. If I compile uMax 4.8 with gcc -Os (= optimize for size) I get a .exe size of 6144 bytes (after stripping).

Perhaps a better indication of the code size would be to look at the object (.o) file, after stripping off the symbol table and relocation information. When I do that for the stand-alone uMax 4.8, I get a size of 2932 bytes. This size also doesn't seem to be rounded. But it is still compiler-dependent.