Winboard Forum

by **Tord Romstad** » 16 Sep 2003, 12:23

Geschrieben von: / Posted by: Tord Romstad at 16 September 2003 13:23:20:

I just downloaded and compiled OliThink 4.1.0 (on a Linux box), and am
currently running a blitz match against my own engine. I have noticed
one small bug:
It appears that OliThink freezes when it recieves the 'post' command
while it is thinking.
By the way, OliThink is really cool. I greatly admire the beautiful,
clear and compact source code. The whole source code is less than
half the number of lines in my evaluation function! If I ever decide
to make a bitboard chess engine, I will study OliThink closely.
Tord

by **Günther Simon** » 16 Sep 2003, 13:06

Geschrieben von: / Posted by: Günther Simon at 16 September 2003 14:06:48:
Als Antwort auf: / In reply to: Bug in OliThink 4.1.0 geschrieben von: / posted by: Tord Romstad at 16 September 2003 13:23:20:

I just downloaded and compiled OliThink 4.1.0 (on a Linux box), and am
currently running a blitz match against my own engine. I have noticed
one small bug:
It appears that OliThink freezes when it recieves the 'post' command
while it is thinking.
By the way, OliThink is really cool. I greatly admire the beautiful,
clear and compact source code. The whole source code is less than
half the number of lines in my evaluation function! If I ever decide
to make a bitboard chess engine, I will study OliThink closely.
Tord

Hi Tord,
I have also running some (20 -40 games)matches between OliThink and
some other new releases (i.e. Gothmog

, at very fast time controls
though, but on my new machine. (RWBC rested for 1 1/2 days,
but round 12 will be finished this day anyway)
Did you notice too that OliThink does not vary from the
pgn book? Here it plays always the same openings, may be
Oliver could insert some randomness in the future?
P.S. It seems he has improved the time management too?
[at least it looks like that in the played 60moves/2min.(: games ]
Best regards,
Günther

by **Uri Blass** » 16 Sep 2003, 13:26

Geschrieben von: / Posted by: Uri Blass at 16 September 2003 14:26:02:
Als Antwort auf: / In reply to: Bug in OliThink 4.1.0 geschrieben von: / posted by: Tord Romstad at 16 September 2003 13:23:20:

I just downloaded and compiled OliThink 4.1.0 (on a Linux box), and am
currently running a blitz match against my own engine. I have noticed
one small bug:
It appears that OliThink freezes when it recieves the 'post' command
while it is thinking.
By the way, OliThink is really cool. I greatly admire the beautiful,
clear and compact source code. The whole source code is less than
half the number of lines in my evaluation function! If I ever decide
to make a bitboard chess engine, I will study OliThink closely.
Tord

I also download the source code and I am interested to know more about olithink mobility evaluation.
I think that it is better to know the best simple stuff for mobility before implementing complcated stuff.

Here is olithink evaluation
int eval(int on_move, int alpha, int beta) {
int i, j, c, p, poseval = 0;
u64 hbit;
int teval = on_move ? -material : material;
if (teval - 130 >= beta) return beta;
if (teval + 130

by **Tord Romstad** » 16 Sep 2003, 13:35

Geschrieben von: / Posted by: Tord Romstad at 16 September 2003 14:35:25:
Als Antwort auf: / In reply to: Re: Bug in OliThink 4.1.0 geschrieben von: / posted by: Günther Simon at 16 September 2003 14:06:48:

I just downloaded and compiled OliThink 4.1.0 (on a Linux box), and am
currently running a blitz match against my own engine. I have noticed
one small bug:
It appears that OliThink freezes when it recieves the 'post' command
while it is thinking.
By the way, OliThink is really cool. I greatly admire the beautiful,
clear and compact source code. The whole source code is less than
half the number of lines in my evaluation function! If I ever decide
to make a bitboard chess engine, I will study OliThink closely.
Tord
Hi Tord,
I have also running some (20 -40 games)matches between OliThink and
some other new releases (i.e. Gothmog , at very fast time controls
though, but on my new machine. (RWBC rested for 1 1/2 days,
but round 12 will be finished this day anyway)
Did you notice too that OliThink does not vary from the
pgn book? Here it plays always the same openings, may be
Oliver could insert some randomness in the future?
P.S. It seems he has improved the time management too?
[at least it looks like that in the played 60moves/2min.(: games ]

Yes, I've noticed the same behaviour. There is no opening variety.
I don't know how the time management was in earlier versions, but
my experience with 4.1.0 indicates that there is still great scope
for improvement regarding time management. I just finished a 10-game
blitz match with Gothmog 0.3.0 vs OliThink 4.1.0, and OliThink always
seemed to play too quickly. The match was played with 4 minutes per
game, with an increment of 2 seconds per move.
Perhaps OliThink does not like time controls with increments? I will
try a 5 0 match now and see if OliThink does better.
Tord

by **Günther Simon** » 16 Sep 2003, 13:59

Geschrieben von: / Posted by: Günther Simon at 16 September 2003 14:59:30:
Als Antwort auf: / In reply to: Re: Bug in OliThink 4.1.0 geschrieben von: / posted by: Tord Romstad at 16 September 2003 14:35:25:

...snip...

Did you notice too that OliThink does not vary from the
pgn book? Here it plays always the same openings, may be
Oliver could insert some randomness in the future?
P.S. It seems he has improved the time management too?
[at least it looks like that in the played 60moves/2min.(: games ]
Yes, I've noticed the same behaviour. There is no opening variety.
I don't know how the time management was in earlier versions, but
my experience with 4.1.0 indicates that there is still great scope
for improvement regarding time management. I just finished a 10-game
blitz match with Gothmog 0.3.0 vs OliThink 4.1.0, and OliThink always
seemed to play too quickly. The match was played with 4 minutes per
game, with an increment of 2 seconds per move.
Perhaps OliThink does not like time controls with increments? I will
try a 5 0 match now and see if OliThink does better.
Tord

Ahh, I remember this behaviour, because first I wanted to do my
new tests with a 2+2 time control and I it seemed like OliThink
always only used the increment time, but not the basic time.
Best regards,
Günther

by **Tord Romstad** » 16 Sep 2003, 15:19

Geschrieben von: / Posted by: Tord Romstad at 16 September 2003 16:19:40:
Als Antwort auf: / In reply to: Re: Bug in OliThink 4.1.0 geschrieben von: / posted by: Günther Simon at 16 September 2003 14:59:30:

Perhaps OliThink does not like time controls with increments? I will
try a 5 0 match now and see if OliThink does better.
Tord
Ahh, I remember this behaviour, because first I wanted to do my
new tests with a 2+2 time control and I it seemed like OliThink
always only used the increment time, but not the basic time.

Yes, 5 minutes without increment worked much better. So much better,
in fact, that the match result was really embarrasing for Gothmog. :-(

Tord

by **Dr. Oliver Brausch** » 17 Sep 2003, 20:56

Geschrieben von: / Posted by: Dr. Oliver Brausch at 17 September 2003 21:56:06:
Als Antwort auf: / In reply to: Re: Bug in OliThink 4.1.0 geschrieben von: / posted by: Uri Blass at 16 September 2003 14:26:02:

I also download the source code and I am interested to know more about olithink mobility evaluation.
I think that it is better to know the best simple stuff for mobility before implementing complcated stuff.

Here is olithink evaluation
int eval(int on_move, int alpha, int beta) {
if (p == PAW_B) { poseval += ((aSrtAttack[i][j][0] & Empty) ? 5 : 3) * pawn_val[i][c]; continue; }
if (p == KNI_B) { poseval += knightmobil[i] * pos_val[j]; continue; }
if (p == BIS_B) { poseval += bitcount(A045(i) | A135(i)) * pos_val[j]; continue; }
if (p == ROO_B) { poseval += bitcount(A000(i) | A090(i)) * pos_val[j]; continue; }
if (p == KIN_B) { poseval -= kingmobil[i] * pos_val[j ^ (!R000BitB[QUEEN[c^1]])]; }
}
return on_move ? -(material+poseval) : (material+poseval);
}
I guess from the names that it analyze mobility but
Unfortunately there are varaibles that I do not understand like P000 and
when I look for that varaible I see that it is defined based on other varaibles
If 100 means 1 pawn then I think that it is too low because I guess that cases when the evaluation is more than 130 based on piece square table and simple ealuation are not very rare.
I see that it is using aSrtAttack that is also used for mobility
knightmobil[i] = bitcount(aSrtAttack[i][KNI_W][1]);
I do not understand what it is.

....
ups, this is 4.0.x, pawns have gone out of this in 4.1.0
This is correct, my only eval is mobility (and pawn structure now)
P000 is easy (and very important). if you look
void upBitHelpers() {
P000 = R000BitB[COL_W] | R000BitB[COL_B];
}
you will see that P000 is the 0-degree (standard) bitboard that contains
ALL pieces. P stands for Piece:-)
thats true. i think this can be improved.
aSrtAttack[i][KNI_W][1] is the bitboard that contains all
fields, where a White Knight, positioned on field i can go.
the more bits, the better:-)
Oliver

by **Dr. Oliver Brausch** » 17 Sep 2003, 21:05

Geschrieben von: / Posted by: Dr. Oliver Brausch at 17 September 2003 22:05:01:
Als Antwort auf: / In reply to: Re: Bug in OliThink 4.1.0 geschrieben von: / posted by: Günther Simon at 16 September 2003 14:06:48:

Did you notice too that OliThink does not vary from the
pgn book? Here it plays always the same openings, may be
Oliver could insert some randomness in the future?

correct. the problem is, that olithink read just once
the pgn file (at the start) an puts the opening in the
normal hashtable.
this is a very effective way, but there is no
randomness. the last opening is the preferred.
i have no idea until now how to do this in a compact way.
perhaps I could use the two-slot hashtable, so you would
get at least a 50% randomness to each move.
Oliver

by **Uri Blass** » 17 Sep 2003, 21:54

Geschrieben von: / Posted by: Uri Blass at 17 September 2003 22:54:10:
Als Antwort auf: / In reply to: Re: Bug in OliThink 4.1.0 geschrieben von: / posted by: Dr. Oliver Brausch at 17 September 2003 21:56:06:

I also download the source code and I am interested to know more about olithink mobility evaluation.
I think that it is better to know the best simple stuff for mobility before implementing complcated stuff.

Here is olithink evaluation
int eval(int on_move, int alpha, int beta) {
if (p == PAW_B) { poseval += ((aSrtAttack[i][j][0] & Empty) ? 5 : 3) * pawn_val[i][c]; continue; }
if (p == KNI_B) { poseval += knightmobil[i] * pos_val[j]; continue; }
if (p == BIS_B) { poseval += bitcount(A045(i) | A135(i)) * pos_val[j]; continue; }
if (p == ROO_B) { poseval += bitcount(A000(i) | A090(i)) * pos_val[j]; continue; }
if (p == KIN_B) { poseval -= kingmobil[i] * pos_val[j ^ (!R000BitB[QUEEN[c^1]])]; }
}
return on_move ? -(material+poseval) : (material+poseval);
}
I guess from the names that it analyze mobility but
Unfortunately there are varaibles that I do not understand like P000 and
when I look for that varaible I see that it is defined based on other varaibles
If 100 means 1 pawn then I think that it is too low because I guess that cases when the evaluation is more than 130 based on piece square table and simple ealuation are not very rare.
I see that it is using aSrtAttack that is also used for mobility
knightmobil[i] = bitcount(aSrtAttack[i][KNI_W][1]);
I do not understand what it is.
....
ups, this is 4.0.x, pawns have gone out of this in 4.1.0
This is correct, my only eval is mobility (and pawn structure now)
P000 is easy (and very important). if you look
void upBitHelpers() {
P000 = R000BitB[COL_W] | R000BitB[COL_B];
}
you will see that P000 is the 0-degree (standard) bitboard that contains
ALL pieces. P stands for Piece:-)
thats true. i think this can be improved.
aSrtAttack[i][KNI_W][1] is the bitboard that contains all
fields, where a White Knight, positioned on field i can go.
the more bits, the better:-)
Oliver

I almost do not use bitboards(use them only for pawn structure) so I do not know standard bitboard but I understand what is the bitboard that contain all pieces(1 for piece in the board and 0 for no piece)
Does it mean the number of moves that a knight can move(capture or empty squares)
I also do not understand what does
bitcount(A045(i) | A135(i)) means
Does it means only part of the diagnols that bishop can move or all of them.
I can guess that it means only diagnols that it moves forward
but I am not sure.
Do I understand correctly that you do not evaluate queen mobility?
I also understand that you multiply it by a constant
You have
pos_val[16] = {10,-10,10,-10,6,-6,8,-8,4,-4,1,-1,5,-5,0,0};
#define ENP_W 0
#define ENP_B 1
#define PAW_W 2
#define PAW_B 3
#define KNI_W 4
#define KNI_B 5
#define BIS_W 6
#define BIS_B 7
#define ROO_W 8
#define ROO_B 9
#define QUE_W 10
#define QUE_B 11
#define KIN_W 12
#define KIN_B 13
#define EMPTY 14

I understand from it that you multiply knight mobility by 6,
bishops mobility by 8 rooks mobility by 4,king mobility by 5 when
I guess based on
if (p == KIN_B) { poseval -= kingmobil[i] * pos_val[j ^ (!R000BitB[QUEEN[c^1]])];.
That there are cases when it is bad to have good mobility(maybe when the opponent has queens)

Uri

by **Dr. Oliver Brausch** » 18 Sep 2003, 21:22

Geschrieben von: / Posted by: Dr. Oliver Brausch at 18 September 2003 22:22:24:
Als Antwort auf: / In reply to: Re: Bug in OliThink 4.1.0 geschrieben von: / posted by: Uri Blass at 17 September 2003 22:54:10:

I almost do not use bitboards(use them only for pawn structure) so I do not know standard bitboard but I understand what is the bitboard that contain all pieces(1 for piece in the board and 0 for no piece)
Does it mean the number of moves that a knight can move(capture or empty squares)
I also do not understand what does
bitcount(A045(i) | A135(i)) means
Does it means only part of the diagnols that bishop can move or all of them.
Do I understand correctly that you do not evaluate queen mobility?
I guess based on
if (p == KIN_B) { poseval -= kingmobil[i] * pos_val[j ^ (!R000BitB[QUEEN[c^1]])];.
That there are cases when it is bad to have good mobility(maybe when the opponent has queens)

Standard means 0 - degrees. I will post something about my Pxxx bitboard
in another thread.
this means the number of fields that is attacked by a knight on square i.
empty, capture or even own piece.
this is only the reachable part of the diagonals. this is important,
because e.g. a bishop has a own pawn in its diagonal the
squares behind do not count.
yeah not at all. queen mobility causes the programm moving queen
too soon.
correctly. this really very cheap and dirty solution. king hides
in the corner when opposite queen is on board.

by **Dr. Oliver Brausch** » 18 Sep 2003, 21:46

Geschrieben von: / Posted by: Dr. Oliver Brausch at 18 September 2003 22:46:46:
Als Antwort auf: / In reply to: Bug in OliThink 4.1.0 geschrieben von: / posted by: Tord Romstad at 16 September 2003 13:23:20:

By the way, OliThink is really cool. I greatly admire the beautiful,
clear and compact source code. The whole source code is less than
half the number of lines in my evaluation function! If I ever decide

Thank you a lot, you are really encouraging me. And right, my aim
is to make a really compact code. But I did not think it was so
clear. But this is difficult to decide for me.
- Oliver

by **Uri Blass** » 18 Sep 2003, 22:19

Geschrieben von: / Posted by: Uri Blass at 18 September 2003 23:19:18:
Als Antwort auf: / In reply to: Re: Bug in OliThink 4.1.0 geschrieben von: / posted by: Dr. Oliver Brausch at 18 September 2003 22:22:24:

I almost do not use bitboards(use them only for pawn structure) so I do not know standard bitboard but I understand what is the bitboard that contain all pieces(1 for piece in the board and 0 for no piece)
Does it mean the number of moves that a knight can move(capture or empty squares)
I also do not understand what does
bitcount(A045(i) | A135(i)) means
Does it means only part of the diagnols that bishop can move or all of them.
Do I understand correctly that you do not evaluate queen mobility?
Standard means 0 - degrees. I will post something about my Pxxx bitboard
in another thread.
this means the number of fields that is attacked by a knight on square i.
empty, capture or even own piece.
this is only the reachable part of the diagonals. this is important,
because e.g. a bishop has a own pawn in its diagonal the
squares behind do not count.
yeah not at all. queen mobility causes the programm moving queen
too soon.

In this case it is the same as piece square table because the number is never changed.
I thought that mobility is only squares that it can reach.
This was clear to me(otherwise it is also the same as piece square table)
I did not understand that it include own pieces but in case of bishops,rook queen it is more than piece square table.
The question that I was interested in is if this is only squares that it can go that are not backward.
In other words if the white bishop is at g2 then if it does not includes
h1 and f1 that the bishop can reach.

I understand but it may be important later in the game.
It is possible to consider it as positive only in part of the cases.
Uri

Winboard Forum

Who is online