something i've played with a little bit:
only look at algorithms with the following
property:
* they every so often update an in-memory score for each board position.
you can then run a timing loop around this and just make the
highest-scoring valid move the play. you can use a signal handler t
Digesting Don's remarks, it seems that a reasonable method would start with
equal numbers of simulations. It could then proceed to try various
optimizations, and compare algorithms which use equal time.
It makes perfect sense for the ultimate goal to be "better performance using
the same time
I have not used time exactly to match up Valkyria and Fuego. But also
with fixed numbers of simulations one can match them up closely in
processor time. And then I do that Valkyria wins something like 41-45%
of the time.
I never intentionally designed Valkyria to work well small number of
On Tue, Jul 7, 2009 at 12:09 PM, Christian Nentwich <
christ...@modeltwozero.com> wrote:
> Don,
>
> I see where this argument comes from, but you are not taking it to its
> conclusion. Unless you can, in the end, show that your algorithm can
> outperform another one with the same time limit, you h
Brian Sheppard wrote:
> Running on your development computer, you might be limited by
> clock time. Running on competition hardware, you might not be.
Only if the algorithm doesn't scale.
Which makes it uninteresting to begin with.
--
GCP
___
compute
On Tue, 2009-07-07 at 17:09 +0100, Christian Nentwich wrote:
> [..] Unless you can, in the end, show that your algorithm can
> outperform another one with the same time limit, you have not proved
> that it is an advance. That is why tournaments are played with time
> limits, not limits on the nu
Magnus,
along the lines of the argument I am trying to make: did you try your
experiments with time limits from 30 seconds per game to five minutes
per game (say), rather than playouts? Using gogui-twogtp this is
relatively easy to achieve.
I am obviously not associated with Fuego, but I gue
Don,
I see where this argument comes from, but you are not taking it to its
conclusion. Unless you can, in the end, show that your algorithm can
outperform another one with the same time limit, you have not proved
that it is an advance. That is why tournaments are played with time
limits, not
On Tue, Jul 7, 2009 at 6:31 AM, Christian Nentwich <
christ...@modeltwozero.com> wrote:
>
> >The problem I think is to find a good tradeoff between heavyness and
> speed. In my test with Valkyria vs Fuego, Valkyria is superior when the
> number of playouts are the same. But >Fuego can play 5 times
Experiments with equal playouts are much easier to control to get accurate
results.
David
>
> What is the motivation in this? I cannot conceive of any good reason for
> running an experiment this way, so I would be interested in opinions. It
> seems to me that making algorithms heavier and the
Quoting Darren Cook :
* The scaling behavior might be different. E.g. if Fuego and Valkyria
are both run with 10 times more playouts the win rate might change. Just
to dismiss an algorithm that loses at time limits that happen to suit
rapid testing on today's hardware could mean we miss out on t
>> * The scaling behaviour might be different. E.g. if fuego and Valkyria
>> are both run with 10 times more playouts the win rate might change
>>
> I am not sure I follow this argument. How do you intend to prove that,
> unless you run the algorithms with 10 times more playouts?
I think s
Darren Cook wrote:
seems to me that making algorithms heavier and then demonstrating that
they are stronger with the same number of playouts misses the point -
why would one not run an experiment under the same time conditions instead?
* The heavier algorithm might be unoptimized;
That
> What is the motivation in this? I cannot conceive of any good reason for
> running an experiment this way, so I would be interested in opinions. It
> seems to me that making algorithms heavier and then demonstrating that
> they are stronger with the same number of playouts misses the point -
> wh
14 matches
Mail list logo
