With all the talk about Michi (which is very nice btw, Petr!), I
figured now would be a good time to do a little more work on my old
super-minimalist obfuscated Go engine, and finally show it off to the
world. Cogito was mostly written in 2008/2009, I only did some
cleaning up/bug fixing/shrinking.
For what it's worth, in gmail, the messages on the new list (including
this one) still have a yellow warning label at the top saying "This
message was not sent to Spam because of a filter you created."
Regards,
Zach
On Tue, Dec 9, 2014 at 9:02 PM, wrote:
> Hi,
> computer-go has moved to
On an initial look, it seems that the shifting, popcounting, and
bitscanning functions can be improved significantly. That's all I
looked at closely, perhaps the other board routines could use some
reworking too.
I'll try my hand at optimizing it if I get the time, but the windowsy
code makes it a
OK, my mistake, I'm rather clueless about scoring methods. And even if
it was just a pure stone count, I still should have written komi > 1.
Zach
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/compute
2009/7/23 Don Dailey :
> How is the center point handled? I assume it plays to the center point as
> black and with either color it just ignores the center point in the symetry
> calculations, right? So if it's playing white, symmetry is broken as
> soon as white plays to the center because
On Wed, Jul 15, 2009 at 10:37 PM, David Fotland wrote:
> So many complex ideas :) Why not just multiply the weight of each pattern
> by a random number and pick the biggest result?
>
> David
That involves generating N random numbers and then doing N-1
comparisons. The n-ary tree has only 1 random
I'll express my opinion here, but keep in mind that my engine (cogito)
has only played 44 games as of now on CGOS. I have a few problems with
separate time controls.
--It dilutes the rating pool. If there is only one time control,
everyone can play everyone. If there are separate time controls, th
2009/4/14 Andrés Domínguez :
> 2009/4/14 Richard Brown :
>> Situational superko can be defined in terms of not permitting a
>> cycle in the game-tree, thus always preserving its acyclic nature.
>> [Positional superko, IMHO, has no such elegant rationale.]
>
> Agree, situational superko seems to me
I'm not familiar with low-level C# stuff, but I imagine the reason is
increased code size.
And I really doubt that the overflow checking for the playout ID is worth
doing. After 4 billion playouts (assuming unsigned 32 bit int) is there any
chance of an intersection not being hit once?
___
Use git anyways ;) I don't use an IDE, but git works great for me from
the command line. After I realized that "git" in pkgsrc was actually
GNU Interactive Tools and not git, it took me just a few minutes to
set up. The basic commands are really easy to learn, especially if you
are familiar with CV
On Sat, Oct 11, 2008 at 8:11 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
>
> I'm going to publish a real simple java reference program and some docs
> to go with it and a program to "test" it for black box conformance.
> (Actually, it will test 2 or more and compare them.) I would like to
> get som
On Thu, Oct 9, 2008 at 5:05 AM, Darren Cook <[EMAIL PROTECTED]> wrote:
> My concern is that to include all the rules of go, including capture
> logic, you need a few hundred lines of code... [snip]
Don't be so sure...
;)
___
computer-go mailing list
co
On Thu, Oct 2, 2008 at 3:48 PM, steve uurtamo <[EMAIL PROTECTED]> wrote:
> The networking issue is somewhat more serious.
> Not the actual network delay, but the mechanism
> that the boinc client software uses to process work requests
> and the interval at which people typically send
> back their r
On Thu, Oct 2, 2008 at 11:16 AM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:
> Zach Wegner wrote:
>> On Wed, Oct 1, 2008 at 10:47 AM, Ian Osgood <[EMAIL PROTECTED]> wrote:
>>> Congratulations! Both for the gold, and for defeating Mogo. I never
>>&
On Wed, Oct 1, 2008 at 10:47 AM, Ian Osgood <[EMAIL PROTECTED]> wrote:
> Congratulations! Both for the gold, and for defeating Mogo. I never
> thought I'd see the day that the Go tournaments would bring heavier hardware
> than the chess championship!
You realize, of course, that Rybka played on
On Wed, Aug 13, 2008 at 5:00 PM, Gian-Carlo Pascutto <[EMAIL PROTECTED]> wrote:
> The problem is that the optimal settings for UCT appear to be much stronger
> on the exploitation side than on the exploration side, making it much more
> likely that such work is really wasted.
I'm not sure it's tha
Interesting. Could you (or someone else) explain how DFUCT works? I'd
imagine it doesn't save all the nodes in memory, but that seems rather
counterintuitive.
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/list
On Tue, Jul 1, 2008 at 4:33 PM, Erik van der Werf
<[EMAIL PROTECTED]> wrote:
>
> That's a pretty good deal!!!
>
> http://64.68.157.89/forum/viewtopic.php?topic_view=threads&p=193819&t=21591
>
> Why isn't there any sponsoring like this for the other tournaments?
>
> Erik
They pretty much have to. T
On Mon, Jun 16, 2008 at 4:42 PM, WSK <[EMAIL PROTECTED]> wrote:
> program oh_iam_sooo_quick_and_dirty;
>
> get_input_move(input);
> .
> .
> .
> do
> {
>set_randomseed(); //sic! :)
>do
>{
>color = white;
>pass = 0;
>if("pass" == play_random_move(color
Wow, just wow. What an amazing video. It's so organic in the way that
it grows. The way it rotates around, and how transpositions pull and
stretch the tree around, and the way that deleted nodes "explode"
away... just awesome.
Also, thanks for turning me on to this General Game Playing stuff.
Soun
> MoGo's parallelization has been published, but with moderate results because
> at that time we were only using ethernet. The
> same algorithm with good networks provide good results in 9x9 and very
> good results in 19x19. The trick is just that sharing only nodes of the tree
> with at least 5% o
On Sat, May 24, 2008 at 6:48 AM, Olivier Teytaud <[EMAIL PROTECTED]> wrote:
>
> By the way, parallelizations (both multi-core and MPI) are *very* efficient.
> The use of huge clusters could probably give much better
> results than the current limit of mogo (between 1k and 1d on KGS with
> 64 quad-c
What you could do is XOR the RDTSC into the seed (or array or whatever
your RNG uses) at the beginning of each playout. That adds to the
chaos but doesn't slow it down much at all.
___
computer-go mailing list
computer-go@computer-go.org
http://www.comput
IIRC the RDTSC instruction is very slow, on the order of 50 cycles. In
addition, I like having deterministic generators so that
hypothetically I could reproduce any result.
In my chess program I use a modified version of Agner Fog's Ranrot.
It's very fast and very random. There's a paper on his si
This could be extended rather easily to an n-ary tree. With 9x9 a
natural choice is 3, but unfortunately 19 is prime.
It's basically a tradeoff between how many adds and how many compares
you want to do. I suppose you would do one update for every pick
(unless you pick an illegal point and want to
> > I think it depends on how you define "smarter". Is that like "more
> > intelligent" ?
> What I mean is that the evaluation function is of better quality - knows
> more about chess in some sense.
Unfortunately, "better" in the case of chess evaluation is about as clear as
better in the sense
On Mon, Apr 7, 2008 at 11:44 AM, Don Dailey <[EMAIL PROTECTED]> wrote:
>
> But I have to say something about the MAC commercials. I find them
> incredibly offensive (like so many other commercials that play on your
> fears and treat us like we are incredible stupid and cannot see what
> they
On 12/4/07, Álvaro Begué <[EMAIL PROTECTED]> wrote:
>
> How do you keep that updated cheaply as moves are made? For instance, if I
> put a black stone next to a white chain, how do I update the OR and AND
> pseudoliberty values for that chain? John's complicated solution only
> requires storing a s
On Nov 13, 2007 2:44 PM, Jason House <[EMAIL PROTECTED]> wrote:
>
>
> On Nov 13, 2007 3:32 PM, John Tromp <[EMAIL PROTECTED]> wrote:
>
> > > Is there any known way to get the best of the both worlds? :-)
> >
> > Yes, you can generalize pseudoliberties by extending them
> > with another field, such
When I started I used this as well. However when I realized how many
times I would be looking at all adjacent intersections I switched to
having an array adjacent[BOARD_SIZE * BOARD_SIZE][5]. In addition to
making the code cleaner, this allows for more compact code size and (I
think) more predicta
In the engine I've been working on for a week or two (I'm brand new to
computer-go)
I use:
typedef int INTERSECTION;
typedef enum { BLACK, WHITE, EMPTY } COLOR;
struct GROUP
{
INTERSECTION base;
COLOR color;
int count;
int liberties;
INTERSECTION children[5];
INTERSECTION parent;
I could pack all of the information into a single array. Here is one
possible scheme which fits in 32 bits and accommodates all board sizes:
3 bits to identify white/black/empty/off-board
9 bits for the hash key (the reference stone)
9 bits for pseudo liberty count
9 bits for stone count
32 matches
Mail list logo
