Thanks! I got this. I just didn't have time to reply.
I like some of this ideas. If an opening book can store the best move, maybe it can be extended to keep a cache of the best moves, maybe that can be even better. Chess engines does something similar, and calls this table "Killer moves". In the search the killer moves will be tried out first in hope to create a cutoff. On the other hand the effect of this may not be as great as in chess as there is no alpha-beta pruning in the search. In our case we just want to do the best move.
I have another suggestion:
when gnu plays money games it assumes both players have infinite amount of money but this may not be the case
an option to add how much money each player has and how much money corresponds to 1 point?
obviously if I have 10 millions for the game and you have 3 millions the bet can't get more than 3 million. If we agree that each point corresponds to 1 million then after a double the bet gets to 2 millions and then the next double is to 3 millions so not a true double. then the cube is dead.
Hmm... at one of the popular online sites (I don't remember the name of it) there was a concept of "Table stakes". I think someone looked into this, but I don't think it was ever implemented.
One last suggestion I have is contempt. Maybe gnu should play/double differently when playing against weak opponents?
This has been experimented with several times (I think Joseph did some experiments 10 years ago), but everything has failed, so far. I think there is a missing factor in such cube decisions. I think if this scheme should be successful you need to add a "skill" estimator to position itself. Like some estimated number describing how much skill you need to play this position correctly. simple race -> low skill needed. Complex backgame -> high skill needed. I have just some vague ideas on how to derive such number.
I have some more questions.
Can it handle the backgame well? I have heard that bots have trouble with backgame and in extreme situations may double in losing position. But is it still true for gnu now? Maybe strong players could beat it that way...
what is different in the new version? is it any stronger?
I don't think it is that bad. I think backgames are handled properly. However, it is one of those things it is hard to say. Should you compare to a human expert on backgames? How do you know the human expert is right?
There is a player called "udacity_capstone" * playing at FIBS. It only plays one-point-matches, so it does not care about gammons and backgammon. I see that it tends to go into backgames quite often. At least more often than I would expect. And I see that it plays it quite well. It doesn't do the "hit-too-early" mistake.
I do not have available time to implement any of these ideas now, so these ideas will be set up on the invisible backlog. Maybe someone else have the resources to look at this?
Best regards,
-Øystein
* "udacity_capstone" was a project I did for my udacity machine learning engineer nanodegree. It basically takes the training data of GNU Backgammon and retrains the main neural network for contact positions. It uses a deeper neural network structure. (I think it's 6 hidden layers now)