[Bug-gnubg] An old bug and possible neural nets input change

[Philippe Michel]

One of gnubg's inputs is the following quantity :

    /* Average number of pips opponent loses from hits.
     *
     * Some heuristics are required to estimate it, since we have no idea what
     * the best move actually is.
     *
     * 1. If board is weak (less than 3 anchors), don't consider hitting on
     * points 22 and 23.
     * 2. Don't break anchors inside home to hit.
     */
    I_PIPLOSS,

The wording is a bit strange (are the comment and the definition from
some old article by Berliner or something like that ?) It is points
that are meant, not anchors, and the numbering is from gnubg's internal
representation and the deep points above are the usual 23 and 24
points.

Anyway, the heuristics seem reasonable, but the code a bit later is :

    /* Piploss */

    nBoard = 0;
    for (i = 0; i < 6; i++)
        if (anBoard[i])
            nBoard++;

    [...]

    /* for every point we'd consider hitting a blot on, */

    for (i = (nBoard > 2) ? 23 : 21; i >= 0; i--)
    [...]

nBoard is not the number of made points, it counts the merely slotted
ones as well... And it has been the case since gnubg's source are
under the current source control system, for at least 19 years...


Even if the error looks gross, this is not too bad in practice :
- the error is present in both gnubg and the training tool so the
  weird resulting heuristic is used consistently
- the number of pips involved is only 1 or 2 when outfield blots count
  for ten times that
- the patterns where the condition leads to a difference are 
  uncommon except (2 points + 1 slot)
 
Still, using "if( anBoard[i] >= 2) nBoard++;", implementing the
heuristics as described and retraining the contact network a little
seem to bring a small improvement as measured by the training tool's
benchmark.


On the other hand, this input is the most expensive one to compute by
far ; more than all the other combined. On my computer, skipping it
raises the calibration result for one thread from 130k pos/s to 250k.

Its coding is rather complicated. It could probably be improved somewhat 
but, since some retraining of the contact and crashed networks would be 
needed anyway, it may be more promising to use instead one or a few 
other similar metrics if they were much faster to compute.