Re: OpenGo Suggestion as Re: Eureka

[Greg Miller <gmiller@xxxxxxxxxxxxxxxxx>]

David Mechner wrote:
> needs of a other algorithms in that particular program. For example, an
> "eye" in our (Tim's and my) program is a /potential/ eye - even a very
> weak eye counts as an eye as long as it might someday become an eye.
> That's to accommodate the binary logic of our life & death algorithm -
> ignoring a lot of details, if a group doesn't have two of these "weak"
> eyes, it can be considered dead and we can stop reading. Another go
> program without this peculiarity would probably want to know only about
> definite eyes or likely eyes, or maybe to have a rating for each eye
> saying how likely it is to end up "real." Essentially our eye patterns
> and data structures would be useless (or worse) for anyone else.  The
> same problem at another level: our eyes have "centers" and "borders."
> All the other parts of our program that ask eyes about centers and
> borders would break if we somehow plugged in a different eye module that
> didn't organize eyes that way. And what if they did, but they meant
> slightly different things (do you know what I mean by center and border
> exactly enough to write code that uses them?)

I suspect that's why the code as described in Jeffrey's last message
doesn't attempt to break down the game logic into modules, but rather
provides move legality checks, display routines, GMP implementation,
etc.
> 
> That being said I think there are a few elements that account for a good
> deal of the startup time for traditional go programs that might be
> written generically enough to be shared, and which might shave a couple
> of years (or more) off the startup time for new go programmers. They
> are:
> 
> 0) GUI (for graphical display of data structures & pattern editing)
> 1) reversion system (& revertible container class library)
> 2) pattern matching system
> 3) low liberty tactics search engine
> 4) ko detection/zobrist hash implementation
> 
> Or anyway that's all i can think of offhand. I think the pattern
> matching system would be the most challenging both in terms of
> programming and design, i.e. getting something that's both general
> enough and efficient enough to be useful to a lot of people. It would
> probably also be the most useful.
> 
> It might be an interesting exercise, at least, to kick around design
> ideas for this kind of thing. Who knows, maybe someone will actually
> write & contribute code for some of these things.
> 
> -David
> 
> --
> David A. Mechner            Center for Neural Science
> mechner@xxxxxxxxxxxxxxxxx         4 Washington Place, New York, NY 10003
> 212.998.3580                http://cns.nyu.edu/~mechner/

-- 
Video games: http://www.classic-games.com/
TW (online game): http://www.classic-games.com/tw.html
Magic cards: http://www.classic-games.com/magic.html
***** ATTENTION NEWBIES: Limit signatures to four lines! *****