I actually agree some form of more de facto cooperation could exist.
Message passing is already used in clusters anyways, some hierarchical
architecture for Go with different providers could be implemented. There
are two immediate problems however:
1. Brown said there are some programs that are much better at some tasks
than others, but I'm not so sure about this and how much stronger would
be a joint effort to compensate the increase in complexity/comm.
overhead/etc.
2. To have a joint effort there would have to be a strong financial
force to pull everyone into the same time table, licensing model, and so
on. Currently research on computer Go seems to be supported by either
commercial endeavors or academic research. Even if this did produce a
stronger player, without a financial force most people would prefer to
do things their own way, instead of adhering to the Go juggernaut. It
would become an effort of just a few "computer Go experts".
The more I think about it the more the word "MoGo" comes to mind.
Gonçalo F.
On 02/10/2015 19:26, Petri Pitkanen wrote:
I think very few people here do not know message passing style of
programming. I just not suited problem at hand. Not very cPU efficient.
This is high speed simulation anyways
2015-10-02 16:53 GMT+03:00 djhbrown . <[email protected]>:
.
"sharing code is typically not going to be practical."
that's not what i suggested. perhaps someone else can explain the concept
of message-passing distributed architecture better than me
_______________________________________________
Computer-go mailing list
[email protected]
http://computer-go.org/mailman/listinfo/computer-go
