Hi, I had nothing to do this morning, so I hacked together a very
rudimentary version of frisbee-twogtp. The GTP support is done by
introducing three new commands: frisbee-play, frisbee-reg_genmove and
frisbee-epsilon. I chose to add new commands for play and reg_genmove
because of the shift in sem
Hm interesting question.
komi
8.0 49%
7.5 50%
7.0 51%
3.5 56%
1.5 58%
1.0 60%
0.5 61%
0.0 61%
Also these win rates do not include the probability of drawing.
Gonçalo
On 14/04/2016 18:08, "Ingo Althöfer" wrote:
> Hi Goncalo,
>
>> accuracy p
>> komi 0.5 0.2
>> 7.5 31% 2
Hi Goncalo,
> accuracy p
> komi 0.5 0.2
> 7.5 31% 22%
> 3.5 43% 36%
> 1.5 48% 45%
> 1.0 49% 47%
> 0.5 51% 49%
> 0.0 52% 51%
Interesting.
Concerning your bot in "normal" 9x9-Go:
Which win rates do you get there for different komi values?
Ingo.
___
>> In testing I've also noted that a komi of 7.0 or 7.5 is no longer
>> reasonable in Frisbee Go...
>
> Tell us more.
> In particular "correct" komi might depend on the parameter p.
I got these win rates at the first turn of matches, in 9x9 with half a
million playouts. These values tend to be sl
Hi Goncalo,
> I also had another restriction in my program that I forgot to mention:
> 6. Both players must be using the same probability p.
this will be the case in Leiden.
> In testing I've also noted that a komi of 7.0 or 7.5 is no longer
> reasonable in Frisbee Go...
Tell us more.
In par
> ... This is a very minimal reduction in code complexity.
> Instead of the move generator having to consider all legal plays plus
> their neighbours,
> this rule allows it just to consider the former. Routines for adding
> the set of neighbours
> to a point set are already quite common in Go engi
1. An intended play must be legal -- no playing on top of a stone hoping
it 'falls' to the neighbor positions.
> The point of the rule is ease of implementation for computer programs,
> to promote adoption. A program that already plays Go will probably keep
> tabs on legal plays, not eve
>>> On frisbee Go itself I used the following definition:
>>> 1. An intended play must be legal -- no playing on top of a stone hoping
>>> it 'falls' to the neighbor positions.
>>
>> Accepted.
>
> What's the point of this rule?
The point of the rule is ease of implementation for computer programs,
>> On frisbee Go itself I used the following definition:
>> 1. An intended play must be legal -- no playing on top of a stone hoping
>> it 'falls' to the neighbor positions.
>
> Accepted.
What's the point of this rule?
I feel it is an unnecessary restriction, similar to the no-suicide rule,
and w
Hi Marc,
thanks for the infos. I try to give answers directly for each point.
(The problem is I have a stubborn cough, for weeks already. Each
day getting my work done is a challenge...)
> Goncalos were on 7th of April. Just copying them here:
> ---
> On frisbee Go itself I used the following def
Goncalos were on 7th of April. Just copying them here:
---
On frisbee Go itself I used the following definition:
1. An intended play must be legal -- no playing on top of a stone hoping
it 'falls' to the neighbor positions.
2. Unintentional plays that are illegal are nulled and don't imply a
desire
Hello MArc,
thanks for your contribution.
> I still haven't seen an exactly specified ruleset for this game.
> Goncalo made some assumptions earlier, which were not yet confirmed.
Oh, from what day is his posting?
> Also I would strongly recommend to not have any clearup-methods
> allowed, but
I still haven't seen an exactly specified ruleset for this game.
Goncalo made some assumptions earlier, which were not yet confirmed.
Also I would strongly recommend to not have any clearup-methods
allowed, but all positions have to be cleared up by "hand" and all
stones on the board in the end are
Hello,
> There is no way in GTP to distinguish intentional from unintentional
> passes, so I suppose the simplest way is to perform things manually.
Manually would mean. In each situation the followiong has to happen:
(i) The program to move proposes a move x or a PASS.
(ii) In case of a move x
Hello,
> There is no way in GTP to distinguish intentional from unintentional
> passes, so I suppose the simplest way is to perform things manually.
That is also my idea.
> Maybe it is an informal tournament and time controls don't really matter.
Yes, assuming that people stick to some "fair"
ere could be bugs, so it's hard to verify.
>
> David
>
>> -Original Message-
>> From: Computer-go [mailto:computer-go-boun...@computer-go.org] On Behalf Of
>> Gonçalo Mendes Ferreira
>> Sent: Thursday, April 07, 2016 6:52 AM
>> To: computer-g
David
> -Original Message-
> From: Computer-go [mailto:computer-go-boun...@computer-go.org] On Behalf Of
> Gonçalo Mendes Ferreira
> Sent: Thursday, April 07, 2016 6:52 AM
> To: computer-go@computer-go.org
> Subject: Re: [Computer-go] Operators for Frisbee Go Simulat
Hello Ingo, if possible I'd like an operator for my program. I'd help
him/her remotely before Leiden.
I'm also letting everyone know my program now has the minimum effort for
frisbee Go (https://bitbucket.org/gonmf/matilda/). I'm looking for other
programs that I can test it with. I lack both a sp
Hello,
one of the games in the Computer Olympiad in Leiden
(June 27 till July 03, 2016) will be "Frisbee Go Simulation"
on 9x9 boards.
I am willing to operate one "foreign" program (David Fotlands
bot is my first choice). And I will find operators for one
or two other programs, when I know until
19 matches
Mail list logo
