194 |
order of perceived difficulty. |
order of perceived difficulty. |
195 |
|
|
196 |
@itemize |
@itemize |
197 |
@item Add more checks in patterns/mkpat.c testing whether the main diagram and |
@item GNU Go passes on the first move as white on small boards with high |
198 |
the constraint diagram are consistent. |
handicap (e.g. 2 stones on 7x7 or 7 stones on 9x9). While it's hard |
199 |
|
to argue that there's no way for white to live, it should be forced |
200 |
@item Complete the conversion to 1-dimensional representation. |
to thrash around for a while. Presumably the opponent is taking the |
201 |
Check all comments before functions to make them agree with |
handicap for a reason. |
202 |
the actual function header. In some cases these comments were |
@item |
203 |
missed when the function was converted to 1D. |
Add more checks in @file{patterns/mkpat.c} testing whether the main diagram and |
204 |
|
the constraint diagram are consistent. |
205 |
@item Break out handling of movelists into its own file and generalize it. |
@item Break out handling of movelists into its own file and generalize it. |
206 |
This is started in 3.1.16. Move lists are used, among other places, |
This is started in 3.1.16. Move lists are used, among other places, |
207 |
in worms.c where it is used to store moves that capture, save, |
in worms.c where it is used to store moves that capture, save, |
208 |
threaten to capture and threaten to save the worm. |
threaten to capture and threaten to save the worm. |
|
|
|
209 |
@item Implement move lists storing important moves for dragons and eyes |
@item Implement move lists storing important moves for dragons and eyes |
210 |
in the same way as it is used for worms. Half eyes are already |
in the same way as it is used for worms. Half eyes are already |
211 |
halfway done. The moves are stored, but not the attack and defend |
halfway done. The moves are stored, but not the attack and defend |
212 |
codes (LOSE, KO_A, KO_B and WIN). |
codes (LOSE, KO_A, KO_B and WIN). |
|
|
|
213 |
@item Make the cache not waste storage on 64 bit systems. |
@item Make the cache not waste storage on 64 bit systems. |
214 |
|
@item Implement detection of superko violation in the board code. We |
215 |
@item Implement detection of superko violation in the board code. We |
probably only want this optionally in @code{play_move()} and in a variant |
216 |
probably only want this optionally in play_move() and in a variant |
of @code{is_legal()}. |
217 |
of is_legal(). |
@item The dragon data is split into two arrays, @code{dragon[]} |
218 |
|
and @code{dragon2[]}. The dragon2 array only have one entry per dragon, in |
219 |
@item The dragon data is split into two arrays, dragon[] and dragon2[]. |
contrast to the dragon array where all the data is stored once for every |
220 |
The dragon2 array only have one entry per dragon, in contrast to |
intersection of the board. Complete the conversion of eye_data, |
221 |
the dragon array where all the data is stored once for every |
half_eye_data, worm and dragon to use the same structure as the dragon2 array. |
222 |
intersection of the board. Complete the conversion of eye_data, |
@item Implement persistent caching in the semeai code. |
|
half_eye_data, worm and dragon to use the same structure as the |
|
|
dragon2 array. |
|
|
|
|
|
@item Implement persistent caching in the semeai code. |
|
|
|
|
223 |
@item Support for ko in eyes.db and optics.c. |
@item Support for ko in eyes.db and optics.c. |
224 |
|
@item Integrate the time handling code in play_gtp.c with the autolevel |
225 |
@item Support for constraints in the eye patterns. |
code in @file{clock.c}. Alternatively, replace them both with something |
226 |
|
better. Basing it on some solid system identification theory and/or |
227 |
|
control theory wouldn't hurt. |
228 |
@item Create a paradigm for handling other types of ko (approach move ko, |
@item Create a paradigm for handling other types of ko (approach move ko, |
229 |
multi-step ko, etc) and then write code that handles them. |
multi-step ko, etc) and then write code that handles them. |
230 |
(Difficult!) |
(Difficult!) |
231 |
|
@item Write a script which plays through the joseki databases and checks |
232 |
@item GNU Go should be able to resign some games. This feature should be |
that the engine really generates a joseki move for all positions in |
233 |
able to be turned on or off since we don't want it during |
the databases. This would also be interesting to run with the |
234 |
tournament play. If all dragons are settled and GNU Go is behind by |
@option{--nojosekidb} option. |
|
a lot, it should be able to resign. |
|
|
|
|
235 |
@end itemize |
@end itemize |
236 |
|
|
|
|
|
237 |
@subsection Long term issues |
@subsection Long term issues |
238 |
|
|
|
|
|
239 |
These issues are strategic in nature. They will help us to improve the |
These issues are strategic in nature. They will help us to improve the |
240 |
playing strength of the program and/or enhance certain aspects of it. |
playing strength of the program and/or enhance certain aspects of it. |
241 |
|
|
242 |
@itemize |
@itemize |
243 |
@item Extend the regression test suites. |
@item Extend the regression test suites. |
244 |
See the texinfo manual in the doc directory for a description of |
@quotation |
245 |
how to do this. In particular it would be useful with test suites |
See the texinfo manual in the doc directory for a description of |
246 |
for common life and death problems. Currently second line groups, L |
how to do this. In particular it would be useful with test suites |
247 |
groups and the tripod shape are reasonably well covered, but there |
for common life and death problems. Currently second line groups, L |
248 |
is for example almost nothing on comb formations, carpenter's |
groups and the tripod shape are reasonably well covered, but there |
249 |
square, and so on. Other areas where test suites would be most |
is for example almost nothing on comb formations, carpenter's |
250 |
welcome are fuseki, tesuji, and endgame. |
square, and so on. Other areas where test suites would be most |
251 |
|
welcome are fuseki, tesuji, and endgame. |
252 |
@item Tuning the pattern databases. These are under constant revision. This |
@end quotation |
253 |
is a sort of art. It is not necessary to do any programming to do this |
@item Tuning the pattern databases. |
254 |
since most of the patterns do not require helpers. We would like it if |
@quotation |
255 |
a few more Dan level players would learn this skill. |
These are under constant revision. Tuning them is a sort of art. It is not |
256 |
|
necessary to do any programming to do this since most of the patterns do not |
257 |
@item Extend and tune the Joseki database. It might be very useful to implement |
require helpers. We would like it if a few more Dan level players would learn |
258 |
a semi-automatic way of doing this. |
this skill. |
259 |
|
@end quotation |
260 |
|
@item Extend and tune the Joseki database. |
261 |
|
@quotation |
262 |
|
It might be very useful to implement a semi-automatic way of doing this. |
263 |
|
The current method based on sgf files become difficult to maintain with |
264 |
|
existing tools. |
265 |
|
@end quotation |
266 |
@item The semeai module is still in need of improvement. (This is underway.) |
@item The semeai module is still in need of improvement. (This is underway.) |
|
|
|
|
@item The connection analysis is today completely static and has a hard |
|
|
time identifying mutually dependent connections or moves that |
|
|
simultaneously threatens two or more connections. This could be |
|
|
improved by writing a connection reader. (This is underway.) |
|
|
|
|
267 |
@item GNU Go does not have a move generator that tries explicitly to build |
@item GNU Go does not have a move generator that tries explicitly to build |
268 |
moyos, or reduce/invade opponent's moyos. Such a move generator could |
moyos, or reduce/invade opponent's moyos. Such a move generator could |
269 |
be built using the same type of code that is used in the owl life and |
be built using the same type of code that is used in the owl life and |
270 |
death reader, or the connection reader mentioned in point 5 above. |
death reader, or the connection reader mentioned in point 5 above. |
271 |
|
@item A much improved combination module. |
272 |
@item A much improved combination module. The combination module of |
@quotation |
273 |
today only finds combinations of threats to capture enemy groups. |
The combination module of |
274 |
A more useful combination module would e.g. find combinations of |
today only finds combinations of threats to capture enemy groups. |
275 |
threats to capture a group or enter opponent territory. It would |
A more useful combination module would e.g. find combinations of |
276 |
also be strong enough to find combinations of strategic moves and |
threats to capture a group or enter opponent territory. It would |
277 |
more indirect threats (a threat to a threat). Possibly it could |
also be strong enough to find combinations of strategic moves and |
278 |
combine threats in AND-OR trees (DAGs?) that could be searched |
more indirect threats (a threat to a threat). Possibly it could |
279 |
using ordinary tree search algorithms. (Revision of combination.c |
combine threats in AND-OR trees (DAGs?) that could be searched |
280 |
is underway.) |
using ordinary tree search algorithms. (Revision of @file{combination.c} |
281 |
|
is underway.) |
282 |
@item Speed up the tactical reading. GNU Go is reasonably accurate when |
@end quotation |
283 |
it comes to tactical reading, but not always very fast. The main |
@item Speed up the tactical reading. |
284 |
problem is that too many ineffective moves are tested, leading to |
@quotation |
285 |
strange variations that shouldn't need consideration. To improve |
GNU Go is reasonably accurate when it comes to tactical reading, but not |
286 |
one could refine the move generation heuristics in the reading. |
always very fast. The main problem is that too many ineffective moves are |
287 |
Also, one should implement some more of the standard tree search |
tested, leading to strange variations that shouldn't need consideration. To |
288 |
optimizations used in alpha-beta readers. |
improve one could refine the move generation heuristics in the reading. Also, |
289 |
|
one should implement some more of the standard tree search optimizations used |
290 |
@item Create a way to quickly assess the safety of a group. This might |
in alpha-beta readers. |
291 |
take into account number of eyes / half eyes, moyo in corners, moyo |
@end quotation |
292 |
along the edge, moyo in the center, proximity to living friendly |
@item Create a way to quickly assess the safety of a group. |
293 |
groups, weak opponent groups etc. The point is that it should |
@quotation |
294 |
involve no reading and that it is quick. This could be used to |
This might |
295 |
make a strategic estimation of how a move strengthens a friendly |
take into account number of eyes / half eyes, moyo in corners, moyo |
296 |
group and/or weakens an opponent group and how strong/weak groups |
along the edge, moyo in the center, proximity to living friendly |
297 |
influence each other. |
groups, weak opponent groups etc. The point is that it should |
298 |
|
involve no reading and that it is quick. This could be used to |
299 |
@item In some positions GNU Go may report a group as alive or connected |
make a strategic estimation of how a move strengthens a friendly |
300 |
with a living group. But after the opponent has placed one stone |
group and/or weakens an opponent group and how strong/weak groups |
301 |
GNU Go may change the status to dead, without going through a |
influence each other. |
302 |
critical status. It would be nice if these positions could be |
@end quotation |
|
identified and logged for later analysis of the GNU Go team. |
|
|
|
|
|
@item Automatic search for missing patterns by analysing games from |
|
|
NNGS. |
|
|
|
|
303 |
@end itemize |
@end itemize |
304 |
|
|
|
|
|
305 |
@subsection Ideas |
@subsection Ideas |
306 |
|
|
307 |
These are some ideas that have been floated on the mailing list. Some |
These are some ideas that have been floated on the mailing list. Some |
310 |
|
|
311 |
@itemize |
@itemize |
312 |
@item A good GUI. |
@item A good GUI. |
313 |
A start is being made with GoThic, a goban widget based on the QT |
@quotation |
314 |
toolkit. This is linked from the GNU Go development web page on |
A start is being made with GoThic, a goban widget based on the QT |
315 |
gnu.org. Other starts have been made based on GTK, but so far |
toolkit. This is linked from the GNU Go development web page on |
316 |
nothing more than a start has been attempted. |
gnu.org. Other starts have been made based on GTK, but so far |
317 |
|
nothing more than a start has been attempted. |
318 |
@item A graphical pattern editor. |
@end quotation |
319 |
This would make it much easier for non-programmers to improve the |
@item A graphical pattern editor. |
320 |
strength of GNU Go. It could also be used as a debugging tool for |
@quotation |
321 |
the programmers. This project has the GUI as a prerequisite. |
This would make it much easier for non-programmers to improve the |
322 |
The challenge here is not to make a tool which makes it easier to |
strength of GNU Go. It could also be used as a debugging tool for |
323 |
create patterns but to make it easier to overview and maintain the |
the programmers. This project has the GUI as a prerequisite. |
324 |
database. |
The challenge here is not to make a tool which makes it easier to |
325 |
|
create patterns but to make it easier to overview and maintain the |
326 |
|
database. |
327 |
|
@end quotation |
328 |
@item Make the engine thread safe and use multiple CPUs on an SMP |
@item Make the engine thread safe and use multiple CPUs on an SMP |
329 |
machine. |
machine. |
|
|
|
330 |
@item Making the engine use many machines loosely connected on the |
@item Making the engine use many machines loosely connected on the |
331 |
internet or in a cluster. |
internet or in a cluster. |
|
|
|
332 |
@item Think on the opponents time. |
@item Think on the opponents time. |
333 |
|
@item A global alpha-beta reader. |
334 |
@item A global alpha-beta reader. This would probably be very slow and |
@quotation |
335 |
could only read 2 or 3 moves ahead. Still it could find fatal |
This would probably be very slow and could only read 2 or 3 moves ahead. |
336 |
errors and improve the moves that GNU Go makes. |
Still it could find fatal errors and improve the moves that GNU Go makes. |
337 |
|
@end quotation |
338 |
@item A pattern based tactical reader instead of the hard coded one. |
@item A pattern based tactical reader instead of the hard coded one. |
339 |
This could be made stronger than the current by taking into account |
@quotation |
340 |
more moves. The challenge is to keep it on focus so that the |
This could be made stronger than the current by taking into account |
341 |
reading does not take forever. |
more moves. The challenge is to keep it on focus so that the |
342 |
|
reading does not take forever. |
343 |
@item A strategic module that identifies high-level goals and then gives |
@end quotation |
344 |
these goals to the rest of the engine. It should be able to |
@item |
345 |
identify if we are ahead in territory or thickness, if we should |
@quotation |
346 |
play safe or if we should play daringly (e.g. if behind). It |
A strategic module that identifies high-level goals and then gives |
347 |
should also identify weak areas where we can attack or where we |
these goals to the rest of the engine. It should be able to |
348 |
should defend. Maybe this module doesn't have to be written in C. |
identify if we are ahead in territory or thickness, if we should |
349 |
Maybe PROLOG, LISP or some other AI language would be better. |
play safe or if we should play daringly (e.g. if behind). It |
350 |
|
should also identify weak areas where we can attack or where we |
351 |
@item A parameter that makes GNU Go play different styles. Such styles |
should defend. Maybe this module doesn't have to be written in C. |
352 |
could be 'play for territory', 'play aggressively', 'play tricky |
Maybe PROLOG, LISP or some other AI language would be better. |
353 |
moves (hamete)', and so on. It could be used to present human |
@end quotation |
354 |
users with different kinds of opponents or to tell GNU Go how to |
@item A parameter that makes GNU Go play different styles. |
355 |
play certain computer opponents in tournaments. |
@quotation |
356 |
|
Such styles could be 'play for territory', 'play aggressively', 'play tricky |
357 |
|
moves (hamete)', and so on. It could be used to present human users with |
358 |
|
different kinds of opponents or to tell GNU Go how to play certain computer |
359 |
|
opponents in tournaments. |
360 |
|
@end quotation |
361 |
@item Generalize representation and handling of threats so that we have a |
@item Generalize representation and handling of threats so that we have a |
362 |
graph representation of threats that can be searched to see how |
graph representation of threats that can be searched to see how different |
363 |
different threats interact. |
threats interact. |
364 |
|
@item An endgame module based on ideas from combinatorial game theory. |
365 |
|
@quotation |
366 |
|
To be really useful this would have to deal with early endgame |
367 |
|
positions. |
368 |
|
@end quotation |
369 |
@end itemize |
@end itemize |
370 |
|
|
371 |
|
|