funny enough : when converting MLA's core to .NET and trying to call it from the http://moggames.net site as a permanent player ...

I noticed that MLA 2.5.5 (the one "on the market", considering that 1.8 is the reference version to beat) was victim of a bug in the setting of weights by phase for some components of the evaluation function ...

So, well, I fixed this bug ... and you know what? The fixed version is weekeer that the one with the bug. Lol

But at least it means that i havent really included the new evaluation terms in the engine yet ...

NOW SOME INFO DISCLOSED ABOUT MLA's evaluation function. here are the terms used in the evaluation function :

- adjacency (connectivity)
- number of marbles
- number of sumitos
- nr of center-related sumitos
- number of ejection threats
- center of mass (in abapro's sense)
- grain (granularity of the  eveluation function i.e. the score is calculated and then an integer division  is applied, thus two positions with a difference of 2 with a grain of 5 will score the same)

The weight of each term evolves based on the game phase. There four game stages :

- opening  : depends on the number of marbles in the 7 center holes
- standard : very limited number of sumitos
- end game : the engine has a high connectivity advantage, it's time to eject marbles
- middle game : other positions

how does the evaluation function tune itself? the type of the start position is calculated. If it has changed from the type of the previous one used in the analysis, the transposition table is reset (searh can become very unstable otherwise ...). of course in each position type, weights are changed as follows :

- opening : occupy the center, weights for the center
- middle game : use standard weights
- standard : it's time to become active, sumitos are more important
- endgame : threaten to eject, and eject, and increase the number of stones difference lol

search is also changed based on position type ...

and the bug i've found means that the engine isnt taking into account the following terms that already exist in my engine :

- nr of marbles on border rings
- size of marble groups / number of marble groups
- pruning of some futile moves (like broadside moves) at "some" nodes

Thank you  

A comparison to what Nacre does:


Things that Nacre do differently

- number of sumitos
- nr of center-related sumitos
Nacre compute sumitos along lines and measure the distance between the line and the center. This gives 3 directions times 5 distances = 15 categories, for input to its neural net.

- nr of marbles on border rings
Nacre has a somewhat similar feature: If you account for symmetry and rotation, marbles can have 9 different locations. Nacre count the number of marbles in each category. This feature was the very first added to Nacre evaluation, but I'm not sure if it is still needed (now that many more features has been added)

Things that are not in Nacre

- number of ejection threats
Nacre must use 1 ply extra search.

- grain (granularity of eveluation function)
I assume this to optimize MTD-search. I expect this gives you a considerable speedup.

- stages
AbaPro proved this is valuable, however with a different approach. AbaPro gradually slides between "middle game" and "end game" states, thus avoiding the need for transposition table reset. When I think of it, AbaPro 2003 did not even have a transposition table. This feature should be included in some future version of Nacre

- size of marble groups / number of marble groups
I too found that Nacre plays weaker when considering size of marble groups / number of marble groups.

- pruning some futile moves at "some" nodes.
:-) this is a very vague definition, but Nacre probaly doesn't do it. Nacre 2003 had no pruning at all. Did you mean "futility pruning" as defined in http://supertech.lcs.mit.edu/~heinz/dt/ ?

- stages
i hope abapro slides back and forth? because noone really knows when endgame starts ... endgame for MLA relates to the positional advantage. More that an endgame concept, it all about deciding when to eject marbles

- pruning some futile moves at "some" nodes. some more info :
(no i'm not talking about the futility pruning, extended futility pruning or razoring, i didnt find a way to get good playing strength with them, probably to the evaluation function lol).

i do "hill-climbing" on connectivity, ie i evaluate the connectivity after each move at node level, if the move decreases connectivity too much, it is discarded. the threshold depends on the type of move, eg broadside moves are discarded more easily than pushes for example. The idea is that if the evaluation function (or a simplified version to save time) decreases too much ... this is probably not a good move.

this selection is not applied at all levels of the tree

additionnally, connectivity is computed by considering that one marble with four neighbors contribute to connectivity more than two marbles with two neighbors.

- number of ejection threats
it is also all about horizon effect

- the MTD(f) - somehow an homemade version - i'm using performs a search at depths
(n modulo 2) ... (n modulo 2) +2 ...(n modulo 2) +4 ... n

the more i write on this ... the more new ideas come to my mind i'm working on the MiGs server right? i have no time to work on MLA right ? lol.