Walter, thanks for yor post, herewith some remarks:
I would certainly want to help to improve the strengths of Horizon especially now that everything is open source.
Anyway thanks for your support. I hope that others are also encouraged more to share ideas and/or source. I think the sources of Feike (especially the evaluation function) are of great help. I also very much appreciate the open and constructive way Rein is sharing ideas and code. In the past also Michel posted all sources related to an older Dragon Engine on the Internet, I'm not sure if this source is still available. I hope also Stef Keetman ( TRUUS), Adri Vermeulen (FLITS) will do the same, as their programs are no longer sold (for Flits it could be that it is still available via the KNDB) and/or competitive.
I also know Harm Jetten as a very supportive person, who shared all details about the DB-handler in Dam 2.x . Think many programs rely on this code (at least Maximus uses the Harm Jetten DB's). I'm not sure but i think this was already a very good cooperation between Michel and Harm at that point in time, and very much supported and accelerated DB-application in Draughts Engines. My ideal is to have one big container in the cloud with all knowledge and sources about many engines. As Draughts is a small world, all of us most likely will not make big money with these programs.
Maybe I only make an exception for Ed !! I really value his contribution towards computer draughts. Basically he did what Stef did with TRUUS, to put something out there which is lightyears beyond current competition. Both Stef and Ed were reasons for me to think further, and to challenge their programs. And for me Kingsrow is still (for the years to come) the proud defacto standard and real value for money. So as long we come not quite close, I have no problem that Ed keeps several ideas for his own. Anyway when you ask him, he will also always provide details, suggestions and many hints. Ed thanks for that, a pity you are not so active anymore here, we miss you...
I find it interesting to think about how a human would evaluate and how Horizon evaluates. For instance, Horizon seems to treat every node completely independent from the game position (i.e. from what is already known). The game position often has many features that do not change often but are critical for evaluation.
A position with a few pieces cannot change into a position with many pieces.
Tempi changes by +1 for a non-capture move. Tempi imbalances are causes by exchanges.
A classical game rarely changes into an attacking game and vice versa.
A lock (hekstelling etc.) usually persists for many moves.
Horizon does not seem to use the fact that these things rarely change during the game. Instead for every node Horizon seems to determine and calculate these things afresh. Would it not be more efficient to call the evaluation function with parameters based on knowledge from the game position? (e.g. call evaluation with is_klasiek = true for the entire search if is_klassiek is true in game position). Would it be more efficient to add tempi information to the node and update during movegen? (Note that it is only the tempi difference between white and black is important to conserve memory). Do you really have to recount to number of locked men for every node?
Basically you are right, and it might be that incremental evaluation update is far more effective. I also thought about that, but it would made my evaluation - search interaction even more complex, so for the time being i put this idea to bed.
A drawback is that with incremental update you need to to update calculations every-move, which in the end (especially when you go really deep), is more costly then doing the math at the end-node. For example in the past i also did the tempi-update after every move. But when i got a new processor with a hardwired POPCNT instruction the incremental update was in fact slower then doing everything at the end-node.
I do some incremental updates for parameters which i need to access at every depth, like number of man, king, hash value (although i think that also Ed has a separate has-function for this, and also does not do incremental update in a Zobrist way).
But if anyone already has some experience with this approach (incremental evaluation update), please share it in this forum.
I also find the interaction between search and evaluation difficult to get my head around. For instance, in the Outpost (voorpost) evaluation the important questions are indeed 1) are there enough defenders? 2) will be defenders arrive on time? 3) are there other defenses than recapturing the attacker (opvangen)? Horizon attempts to answer the first two questions in the various Voorpost evaluation functions. The question whether the defenders will arrive on time is answered by calculating the distances. For a human the second question is probably more something for a restricted search. By a restricted search I mean a search that only considers moves that are relevant for the issue being evaluated. In this case only moves that are aimed at attacking or defending the outpost.
I think that a human uses such restricted or targeted searches a lot to evaluate a position. Is the outpost safe? Is a breakthrough possible? Who controls the wings? Could a computer implement this?
The outpost is really a "animal" where it might be preferable to better sync between evaluation and search, as the current static approach is so heavy, and the code hardly readable and/or maintainable. Think that Gerard (DAMY) uses this approach. Would be good if he provides some status information related to his novel approach, as I also believe that a better dynamic cooperation between search and evaluation will pay off in the end (and is more alike how humans "think").
Some other areas that interest me personally are:
1) Add Killer-rule to Move Generator
2) Use CMoveGen64 code to get legal moves to Web GUI.
3) Use CDatabase64 code to retrieve end game db info with the Web GUI.
4) Try to get search to work massively parallel on Xeon Phi
5) 3-Hirn approach, i.e. start multiple searches with different parameters or eval in parallel and arbitrate best move.
At least the good news is that with the code available these days, you have a head-start to start with these ideas.
In my case the 5 areas I need to work on:
- Better Horizon evaluation, adding some features, and improving some functions (like free-path, run-away, or breakthrough, or whatever name is used...).
- Making the Horizon evaluation faster. Really need to do a profile, because i have no clue what is consuming most time (but i suspect the outpost routine).
- YBWC parameter tuning, I think the Xeon Phi is an interesting concept (do you have one?), but I doubt if Draughts is really good scalable towards the 50+ cores.
The same is valid for GPU, unlimited power, but hardly feasible for this type of problem (but maybe the Chess folks will find something, at least there is regular posting in the multiple forums).
- The current search goes really deep (and has really potential) , but often the baby is thrown away with the bathwater, so need to do something better here.
- An auto generated opening BOOK.
So never a dull moment...
Bert
