# [Computer-go] parameter optimization (clop & others)

Brian Sheppard sheppardco at aol.com
Thu Feb 7 13:36:57 PST 2013

```I have a rationale for choosing "3 or 4" as the optimum. Not theoretically
sound or anything, but this is how I am actually looking at.

The number of parameters in a Clop model with N input variables is (N + 1) *
(N + 2) / 2. Here is a table:

1 --> 3

2 --> 6

3 --> 10

4 --> 15

5 --> 21

The ratio of model parameters to input variables is 3:1 if the input
variables is 1 or 2. In some sense, you get the cross-product term "for
free" when you run Clop with 2 input parameters.

As you add input variables, then the number of model parameters rises. For 3
input variables, the ratio of model parameters is still pretty close to 3:1.
But for 4 or more input variables, then the cost of trying to benefit from
cross-products of input variables starts to rise quickly.

Since cross-product terms are almost always close to zero, it does not make
sense to pay much. In other words, I would be better off optimizing each
input variable separately.

This is why I try to optimize 2 or 3 input variables per Clop run. It
happens that a lot of Pebbles search features are parameterized with a small
number of floating point numbers, so this works OK for many use cases.

I could be better off if I could run with 30 input variables and the 30 most
valuable cross-product terms. The Clop model would have 91 parameters. But
the downside is that the run could take 9 times as long as a run with 3
input variables, and I don't know if I want to "freeze" a version of Pebbles
for that long.

So even with the ability to choose cross-product terms, I might still only
optimize 6 input variables concurrently using Clop.

Brian

From: computer-go-bounces at dvandva.org
[mailto:computer-go-bounces at dvandva.org] On Behalf Of Olivier Teytaud
Sent: Thursday, February 07, 2013 3:08 PM
To: computer-go at dvandva.org
Subject: Re: [Computer-go] parameter optimization (clop & others)

Thanks Brian for this comment:

1) It is very important to limit the number of parameters concurrently
optimized. E.g., to 4 or fewer. The optimum might be 3.

I do something similar (with other optimization algorithms); in large
dimension, I optimize only a few parameters,

and then I slowly add new parameters. A little bit like Sieves method in
statistics.

I try to mathematically justify this process, which is not that much
documented in noisy optimization papers and which

might be a good optimization trick...

Best regards,

Olivier

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://computer-go.org/pipermail/computer-go/attachments/20130207/ba96e3cb/attachment.html>
```