Chess programmers should take notice ..

[Michael Sherwin]

... of the grand demonstration by Dr. Oliver Brausch that is Olithink 5!

It was when Fabien added mobility-eval to Fruit 1.5 that caused a big jump in strength for Fruit 2.0!

Now with the OliThink 5 series Dr. Brausch has created an engine that only has a mobility-eval and nothing else. Not even any pawn structure code or piece_square_tables.

Whom amoung us chess programmers would have believed that such a program could be a 2400+ (CCRL) engine?

Yes, yes, yes I know that mobility is a part of many chess engines, but my point is, is that none have demonstrated before (to my knowledge) just how important mobility-eval really is! OliThink plays in a simple, pure and strong fashion. Other knowledge should just supplement this!

I can now see that mobility should be the core of a chess engines evaluation. OliThink 5.1.6 wins brilliant strategic games and lots of them when its pawn structure is a shambles. It also looses games because of its pawn structure. The trick then to increase the playing strength of OliThink would be to add a gentle pawn-eval that will influence OliThink to keep better pawn structure when it does not hamper the positive effects of mobility.

In general then, evaluation terms should not overpower the mobility-eval. An exception may be that various material imbalances should lesson its importence therefore allowing other evaluation terms to dominate. An example would be that if one side sacrificed a rook for a knight, then mobility importance can be decreased slightly and outpost should be made more important.

Anyway, I think that OliThink 5 if studied closely by chess programmers will lead to new insights and is a Grand Demonstration

$0.02

[OliverBr]

Thank you, Michael,
i think this is way too much praise, but it motivated.

I want to take the opportunity to explain OliThink's concept:

Mobility

Every single piece (except king) gets for every field it can reach points (centipawns). Bishop 8 points, Knight 8 points (in 5.1.7 changed that to 6 points), Rook 4 points, Pawn 4 points and the Queen 1 points.

This includes fields that are occupied by own pieces (backing) and foreign pieces (attacking)

(Hard) Pinned pieces only gets points in the direction they can move, pinned knights don't get any direct mobility point.

But there are three additional "mobility" scorings that are implemented to do important evaluation of chess stuff, that doesn't look mobility first.
1) King safety. OliThink rewards every piece with a high score (pinned or not) if it attackes a field that is next to opp's king.

2) Endgame transition. In endgames, but no sooner, own king gets a mobility score similar to own pieces to prevent him staying at the border/corner. I don't like this one, but it is necessary.

3) Free pawn/hanging pawn. This is newest addition. A free pawn can't really be stopped by opp's pawn, so he get addition mobility bonnus. A hanging pawn can't be freed by own pawns, when it is blocked. Not: A lonely free pawn is a hanging pawn, too.

That's all about mobility implemented. What OliThink misses in eval:

-Pawn structure except for the free/hanging pawn
-Queen shouldn't move in the first N moves (??)
-Rook on 7th line (this is something that Crafty loves)
-Trapped Bishop stuff
-Piecesquares
-Castling Bonus
-Pawn shelter
-Bishop Pair
-Rook on free files
etc..etc...

To be honest, I don't like most of these things, so I never will implement them. Evaluation should be continous and natural, but what is natural in the rule, "Queen shall not move until move 12".?

Treesearch

My first idea was to make a absolute less-free search. This means: no approximations and no tree cutting. I had to get rid of this idea for Qsearch.
OliThink still does is exact in search at depth > 0 (no razoring, no futility pruning, no LMR) except for null move.

In qsearch it was not possible to avoid some tree cutting. It uses some kind of delta pruning and SEE (this came very late, wanted always to avoid the non-exact SEE) to cut the tree in qsearch. I am not very happy with both, especially the delta pruning could be improved.
The tree in qsearch is still very big compared with other engines.

Move generator

This was the motivation I had for OliThink 5
I used in OliThink 4 already bitboards (with "rotated" bitboard) and made a pause of some years after OliThink 4. I never thought I would come back to chess programing since one day I was reading something about bitboards again and thought, it must work without those complicated "rotated" bitboard. So I invented (thought so) a new bitboard concept without rotated bitboards.
Later I saw that is was existing. I first thought that it was "magic move generation" then was corrected that I only reinvented some kind of "kindergarten move generation".
But this is really fast and nice. I think this is the best approach.

In OliThink 5 I avoided successfully any kind of piecelist, extra board, rotated bitboards etc. All position information is stored and retrieved in the 10 bitboards:
u64 pieceb[8];
u64 colorb[2];

(Note: 6+2 would be enough, but my piece enumeration includes EMPTY and ENPASSANT, so the 8 stands, but pieceb[0] and pieceb[4] are not used)

Perhaps this can give some insight in what is happening.
Oliver Brausch[/b]

[Michael Sherwin]

Hi Dr. Brausch,

And thank you for your program and for this explaination!

I struggle to understand anyones sources, so a clear and concise explaination is worth much more to me.

you might find this amusing that I use the same values for mobility as you do/did N=8, B=8, R=4, except Q=2 (was Q=1 before). I even have extra points for attacking into the king field. I just precalculate this into piece square tables at ply 0 and again at ply 1.

However, the piece square tables are also loaded up with a lot of the stuff that you do not like. I wonder how much of this extra stuff is really counter productive.

[smcracraft]

Pawn evaluation seems cheap with the pawn hash table.

Writing the code efficiently is not that important I would
think because of the pawn hash table taking care of
repeat lookups...

So, for that mobility-only-eval, add pawn hash table,
don't feel guilty about your pawn structure code efficiency,
add some kind of king safety, and then eliminate all bugs
(much harder to do than one would think.)

Building up the engine gradually, slowly, a piece at a time,
with heavy testing, etc.

[Uri Blass]

<snipped>

... of the grand demonstration by Dr. Oliver Brausch that is Olithink 5!

It was when Fabien added mobility-eval to Fruit 1.5 that caused a big jump in strength for Fruit 2.0!

Now with the OliThink 5 series Dr. Brausch has created an engine that only has a mobility-eval and nothing else. Not even any pawn structure code or piece_square_tables.

Whom amoung us chess programmers would have believed that such a program could be a 2400+ (CCRL) engine?

I do not find it surprising.
search is important in chess and you do not need good evaluation to get
2400+(CCRL) engine.

I believe that with strelka's search you can also get 2400+(CCRL) engine with only piece square table evaluation but only mobility seems to me better than only piece square tables.

Uri

[grant]

Oliver

Do you reward mobility points even if a square is attacked by an enemy pawn?
And how about Xrays if a bishop or rook can reach an own queen?

Grant

[Uri Blass]

Oliver

Do you reward mobility points even if a square is attacked by an enemy pawn?
And how about Xrays if a bishop or rook can reach an own queen?

Grant

For the first thing I think that it does not make sense not to evaluate mobility if a square is attacked by enemy pawn.

If a square is attacked by an enemy pawn it means that the square is not going to be attacked by the enemy pawn when the enemy pawn moves and the fact that the opponent needs the pawn as a defender in case that he wants to prevent some move is an obviouis advantage.

The pawn is not always an effective defender and there are sacrifices
in chess so there is a difference between cannot move and cannot move without being captured.

Uri

[grant]

Uri

Not sure I follow your logic. If preventing a move is/could be an advantage, would you not want to express that advantage in the score?
In think in most cases the pawn is an effective defender. Yes there are sacrifices, the search should find that, not a mobility evaluation.

Grant

[Zach Wegner]

For the first thing I think that it does not make sense not to evaluate mobility if a square is attacked by enemy pawn.

If a square is attacked by an enemy pawn it means that the square is not going to be attacked by the enemy pawn when the enemy pawn moves and the fact that the opponent needs the pawn as a defender in case that he wants to prevent some move is an obviouis advantage.

The pawn is not always an effective defender and there are sacrifices
in chess so there is a difference between cannot move and cannot move without being captured.

Uri

Well by that logic you could get rid of a lot of evaluation terms.

Personally I evaluate both regular mobility and "safe" mobility (squares not attacked by opponent pawns). It is noticeably weaker without both.

[YL84]

Hi,
what is really necessary to have 2400 with a chess engine?
Am I wrong or some extensions in the search are very important,
for example when there is a passed pawn ,when the king is under attack,
when the castle is weak...?
If it is not in the eval it is somewhere in the search, you need a very good selective search...

Yves