Multiple EVAL

[Rebel]

I am toying with the idea to make my EVAL a standalone library which (starting) programmers can link to their engine. As such it can (for instance) serve as a second opinion EVAL during search or for other purposes, such as research.

Furthermore I plan to pick one of the freely available sources out there and make it ready as a framework for more of such standalone EVAL's.

I am not sure if this 1) doable and 2) if there is enough interest.

So I drop it here first for discussion.

[Edsel Apostol]

It seems interesting. I would be curious how it would affect playing strength of our engine for instance.

One of the first things you may need to consider is the interface to the other engines. How would an engine pass the position structure to the library efficiently. One way would be EPD/FEN but it might be too costly.

[Don]

I am toying with the idea to make my EVAL a standalone library which (starting) programmers can link to their engine. As such it can (for instance) serve as a second opinion EVAL during search or for other purposes, such as research.

Furthermore I plan to pick one of the freely available sources out there and make it ready as a framework for more of such standalone EVAL's.

I am not sure if this 1) doable and 2) if there is enough interest.

So I drop it here first for discussion.

Some sort of API would be necessary to make this work and any API you use would be a drag on performance.

I would suggest a set of function and/or MACRO's that allowed the engine authors to write the most efficient code he could. For example macros to query a squares content, perhaps provide a bit mask of pawns on a specified file, or whatever it is that rebels evaluation calls for.

From reading your description of rebel I see that you do much with tables indexed by a piece on a square, so it may be most useful at evaluation time to first get the equivalent data structure from the foreign engine.

But it looks like a really cool project to me. When I was at MIT I pondered the possibility of a highly modular chess program where people could plug in their own evaluation, search, and perhaps other such things. But chess programs are messy and it's difficult to get a clean separation without affecting performance.

[BubbaTough]

I am toying with the idea to make my EVAL a standalone library which (starting) programmers can link to their engine. As such it can (for instance) serve as a second opinion EVAL during search or for other purposes, such as research.

Furthermore I plan to pick one of the freely available sources out there and make it ready as a framework for more of such standalone EVAL's.

I am not sure if this 1) doable and 2) if there is enough interest.

So I drop it here first for discussion.

For some reason I think this was already been tried before, and I was chatting with some author in OpenWar about it. Perhaps DIRTY had a separate eval (though it has since been merged)? You may want to ask Andres about it, and if its true ferret out some lessons learned.

-Sam

[laoliveirajr]

When you talk to a chess player over a chess engine, this immediately imagine something like a GM help their chess training.
This helper will give their advice to both points of view of the board.

Now imagine if the chess player had at his disposal two GM to help him, each giving their advice from your side of the table.

... But chess programs are messy and it's difficult to get a clean separation without affecting performance.

To have a clean separation without confusing it would be necessary to separate also the call to the function EVAL.

I figured it would only be possible with functions SEARCH and QUIESCENCE_SEARCH different, each making calls to their different functions are single EVAL.

So that we may satisfactorily engine running we need to have two sets of functions, each calculating TREE_NODES your point of view of the table.

Each side would then have its set of functions EVAL, SEARCH, QUIESCENCE_SEARCH, DO_MOVE, UNDO_MOVE, SWAP, and OTHERS if necessary.

This is the engine Capivara. ***[1] With an assessment as TSCP_evaluate/Kaufman_old_evaluate***[2] in the first person, against a mix of exists and is common in most engines, in the other side of the table ...

***[1] Image "How Capivara LK 0.08b0x works... " in sixth post, in "Start EndGame - A matter of fine tuning ???"
http://talkchess.com/forum/viewtopic.ph ... 03&t=47173

***[2] "The Evaluation of Material Imbalances" << http://home.comcast.net/~danheisman/Art ... alance.htm >>.

http://talkchess.com/forum/viewtopic.ph ... 87&t=45512

[PK]

Perhaps we can start by defining input and output of such eval function. My take would be:

INPUT:

- 12 piece bitboards (or 6 piece bitboards and 2 color bitboards)
- alpha and beta (so that lazy eval can be used)
- OPTIONALLY 2 * 5 piece counts (they can be derived from bitboards, but I imagine this data is used quite often)
- OPTIONALLY 2 * king square (as above)
- OPTIONALLY 2 piece/square scores (as some an engines maintain them in a board structure)
- OPTIONALLY hash signature
- OPTIONALLY pawn hash signature

OUTPUT:

- full eval
- OPTIONALLY fast eval (material + pst? material + pawn struct?)
- OPTIONALLY printout of evaluation components

[MikeGL]

I am toying with the idea to make my EVAL a standalone library which (starting) programmers can link to their engine. As such it can (for instance) serve as a second opinion EVAL during search or for other purposes, such as research.

Furthermore I plan to pick one of the freely available sources out there and make it ready as a framework for more of such standalone EVAL's.

I am not sure if this 1) doable and 2) if there is enough interest.

So I drop it here first for discussion.

Sorry for this lousy question, but it sounds ambiguous to my narrow mind:

By the word "library" and "link" do you mean *.lib (for C) and
Link (for those separate object files after compiling),

or

a library of Eval which is accessed _not_ on "compile time" but on runtime. Like
providing a bunch of *.DLL's (for Win OS) and *.so (for Linux OS).

I think the latter type of Library can allow Dynamic Eval's where Opening Eval, Middle Game Eval
and Endgame Eval can be accessed by just calling the correct *.DLL or *.so at runtime. Which of course can speed up all current engines.


P.S. I am not a pro in programming unlike you guys, so pardon this funny question.
Any reply would be appreciated.

[asanjuan]

I am toying with the idea to make my EVAL a standalone library which (starting) programmers can link to their engine. As such it can (for instance) serve as a second opinion EVAL during search or for other purposes, such as research.

Furthermore I plan to pick one of the freely available sources out there and make it ready as a framework for more of such standalone EVAL's.

I am not sure if this 1) doable and 2) if there is enough interest.

So I drop it here first for discussion.

Some sort of API would be necessary to make this work and any API you use would be a drag on performance.

I would suggest a set of function and/or MACRO's that allowed the engine authors to write the most efficient code he could. For example macros to query a squares content, perhaps provide a bit mask of pawns on a specified file, or whatever it is that rebels evaluation calls for.

From reading your description of rebel I see that you do much with tables indexed by a piece on a square, so it may be most useful at evaluation time to first get the equivalent data structure from the foreign engine.

But it looks like a really cool project to me. When I was at MIT I pondered the possibility of a highly modular chess program where people could plug in their own evaluation, search, and perhaps other such things. But chess programs are messy and it's difficult to get a clean separation without affecting performance.

Years ago, back in the 2002, I implemented something similar in Java. My degree project was a framework where any programmer could implement their own eval and search functions, and combine every implementation at their likes. The problem was that the eval was very dependent on the board representation.
basically, there was:
- a class "searcher" with an abstract method "search" ,
- and a "board" class with their own board representation and an abstract "eval" method. There was also an "eval_move", for move ordering purposes.



Each searcher could call another searcher at his horizont depth, so you could combine any different searches to build very different search trees.

The basic implementation was a class "alpha-beta" derived from "searcher", a "quiescence_search" derived from "searcher", and a "my_board" class that implemented a very basic PST + bishop pair evaluation.

There was also a "factory" class to instantiate every object properly.

At that time, CPW didn't exist and everything was more difficult than today. I didn't know anything about bitboards...

Of course, there were lots of bugs hidden somewhere, and the performance was really poor. Horrible performance, in fact. This was the main reason to make a change, and this was the origin of my current engine: Rhetoric.

I think that what you really need is to develop a standarized board representation, well documented, and some virtual methods so any developer could fill the gaps.