Fri 06 Apr 2007 08:51:48 AM UTC, original submission:
I am using the latest gnubg both on Windows and a Linux-CLI gnubg -t. I am playing variant Hypergammon_3 (I got the hyper3.bd database as well as built my own, which of course turned out to differ very little from the 2003 version original hyper3.bd found on the web - I checked using the code and the ingenious 3-byte endian-independent storage system. The values are indeed within 1.0e-05 ).
If played with the cube, a match to 3 or 5 is won by any amateur (like myself) even while making completely random moves - 75-80% of the time! In fact, it takes serious effort to LOSE to gnubg. Doubling behaviour is absoulutely erratic; gnu frequenly redoubles until the whole match is reduced to one game. Together with very silly moves (and strange fear of taking opponents pieces) - GNU manages a solid 20-25% win rate (75-80% loss rate). This is a completely discouraging result, if one tries to demonstrate e.g. to one's students how GNU behaves in a <u>strongly solved game</u>! GNU must be a killer in hypergammon! But it isn't!
However, without cube, it plays rather decenly with 70% win rate or similar, and makes competent moves.
I suspect the root of this is somewhere in the eval.c - in the CubeEfficiency routine where there's a simple stub value of 0.60 is returned with a /FIXME/ commentary.
//.....-----------------------------------......
static float
EvalEfficiency( int anBoard[2][25], positionclass pc ){
/* Since it's somewhat costly to call CalcInputs, the
inputs should preferebly be cached to same time. */
switch ( pc ) {
case CLASS_OVER:
return 0.0; /* dead cube */
break;
case CLASS_HYPERGAMMON1:
case CLASS_HYPERGAMMON2:
case CLASS_HYPERGAMMON3:
/* FIXME */
return 0.60f;
break;
//-----------------------------------......
There's some comment nearby there that with VARIATION_STANDARD the cube efficiency value is not really important because of an N-ply evaluation. But for Hypergammon, there's hardly any N-ply eval. It is my understanding that it is 0-ply by definition in Hyper with a look-up in the hyper3.bd file for all precomputed equities and probabilities and simply picking the move with the nest result.
Do you agree that the cube efficiency might be something that must be implemented in the proper place in the code by someone who is fluent in this part of the code? Or maybe something else might be spotted by the maintainer of this part of the code?
Thank you in advance.
Serge
|