floats or ints? (Re: [computer-go] Re: Remarks on the Indigo-Paper)

[Chrilly]

>
> I have done it both ways in various programs. Currently I don't see a
> compelling reason to go either way. Of the top of my head, here are
> some (admittedly minor) advantages for floats:
>  * It's easy to feed floats into standard implementations of special
>    functions like sqrt and log.
I have in Hydra what is conceptunally a log. But I use a table-lookup with 
the result rounded to integer. This has the additional advantage that its 
more flexible. I can tune it more to the needs of the program. E.g. for the 
first few values it rises slower, from a certain value onwards its flat. 
Once upon a time these maths operations were infinite expensive. So no 
speed-aware programmer would use it. They are still expensive, but not 
infinite anymore.

>  * It's easy to feed floats into standard implementations of numeric
>    transformations like FFT.
Although E.v.d.Werf proposed some time ago an FFT, I do not know what to do 
with an FFT in a programm. Floats are certainly handy in DSP and graphics 
applications. MMX was before only int-based, but due to the requirements of 
these fields parallel float operations are now also supported (and the Intel 
engineers have solved their main problem: What to do with the millions of 
gates).


>  * It's easier to read some kinds of expressions when you don't need
>    to think about reintroducing exactly the right number of
>    fixed-point denominators. For example, imagine several
>    values which represent subprobabilities, like the probability
>    of making an eye and the probability of connecting a pair of chains.
>    An expression combining such subprobabilities, perhaps into the
>    overall probability of making life under the approximation that
>    all the subprobabilities are independent, tends to be relatively
>    easy to write and check for floats, and noticeably more tedious
>    for fixed point fractions embedded in ints.
I use in Suzie Probabilities for move-ordering. An extension of the 
history-heuristic. One counts the number of times a move was tried and the 
number of cutoffs he has produced. The Probability is simply calculated as:
MoveProb=(History[move].CutOffs<<5)/History[move].Used.
(The Shift is not really done, Update is not incremented by 1 but by 64. 
Division by 0 can not happen, because one initializes both values with 1).

This measure has become recently popular in chess for the so called 
History-Pruning. When the probability is below a given thresold, the line is 
reduced by 1 (or 2) Plies.
The Probablity above is accurate enough, because its anyway only a crude 
estimate of the quality of a move. Game programming is no precise 
mathematical operation. One uses what we call in German "Daumen mal Phi" 
(dumb times Phi) rules. There is no point to make the measurements make more 
precise than the underlying concepts are in reality.
It does not work so good in Suzie, because the eval is currently too stupid 
and the search-results are therefore not reliable.

Chrilly