[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: computer-go: Sharing Go modules



People have talked a lot recently and in the past on this list about shared
modules, but my prediction is it will never work.  I think it is most
productive is to freely discuss algorithms and representations here on this
list and write your own code the way you understand it best.  And if you
have some code that you wish to share, by all means, share it.  Perhaps
someone can use it as is, but more likely, they can learn from the algorithm
implemented and somehow apply it to their own goal in their own system.  If
more than one people want to cooperate on a single project (gnugo, others)
that's great, too.  But to think that you will be able to get people to
write modules in a language other than there first choice, using
representations other than their first choice, with interfaces other than
their first choice, is my opinion, naive and a waste of time.  I think the
people who take part in these discussions must be under the impression that
they and all other discussing parties will be happy with a collective
decision.  I don't see how that is possible.


-----Original Message-----
From: Grajdeanu, Adrian [mailto:adrian.grajdeanu@xxxxxxxxxxxxxxxxx]
Sent: Thursday, May 17, 2001 12:32 PM
To: 'computer-go@xxxxxxxxxxxxxxxxx'
Subject: RE: computer-go: Sharing Go modules


My take is biased towards C++, but I guess it doesn't have to be limited to
C++. I follow the generic programming model and such I have a struct named
coord that encodes the coordinates somehow. In most of the cases I don't
care how the coords are encoded, just that passing it as an argument is easy
(32 bits). Then I can start off with an implementation that is not very fast
(like needing to multiply by 19 every time I need to index the board) and
further down the line, if this turns out to be the bottleneck, I can change
it to something more efficient. Can't all these algorithms that we're trying
to share be written such that they don't care how the data is stored?

While I could propose something for C++ along these lines, I don't think I
am the best to propose it for Java. What do you guys think? Any takes?
Volunteers?