Re: [computer-go] Statistical Significance (was: SlugGo v.s.ManyFaces, newest data)

[Don Dailey <drd@xxxxxxx>]

> I would agree with you if the posted results concerned versions A and B of
> the same program. Since the most recent results are versus ManyFaces, an
> alltogether different program, I think the outcome should have more
> credibility. Unless the program was specifically tuned to play against
> ManyFaces beforehand, something I understood wasn't the case.

Hi Mark,

I'm not trying  to refute you here.  I also  believe these results are
impressive because  we are  now talking about  quite a few  games with
very good overall results.

I don't think  I communicated my point very clearly.   I see that what
you are talking about is "intransitivity" and your point is completely
valid  but it isn't  the same  point as  mine.  So  I agree  with your
observation that testing against  Gnugo isn't as convincing as testing
against ManyFaces.

Let me restate hopefully in a  less clumbsy way: "Parallel gnugo" is a
modification of the  original Gnugo and most modifications  of a given
code base do  not result in enormous improvements.   One can choose to
factor that "belief"  into the statistics of a  short match and that's
what I'm suggesting we might do here.

But  maybe this  isn't  necessary here  anyway  because this  parallel
version of Gnugo may be more than just a minor modification.  They are
indeed throwing a lot of hardware at the problem, so my suggestion may
not be very relevant.

   

> Given the results posted I think it clearly shows a 4 stones difference over
> ManyFaces. Maybe further testing will adjust it down to three stones, but my
> gut-feeling says that's going to be very unlikely. And even when it does,
> the results are very impressive.

>     Mark Boon


Yes, I'm  pretty happy about his  results.  I've always  tried to make
the point  that most Go  programs are not  really scalable and  do not
take proper advantage of computer  hardware, and this program (so far)
is showing that this is possible  in a practical program.  I know that
you have  tried to make this same  point, that go programs  need to be
scalable.

- Don
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/