[computer-go] survey : Debuging a board implementation.
Hi. - WHAT TOOLS DO YOU USE FOR DEBUGGING BOARD IMPLEMENTATIONS ? - - Here is how i do it : - I have made quite a few board implementation in the past years. Initially i used a custom made dirty Java-swing-visualizer. It was very usefull to get started, as we had the goal to reach the 20k simulation/s marks. We used not very user-readable structures, and so it was very helpfull for testing purposes. The java-swing-visualizer enabled me to visualize easily different views on the board-state. Later on, when switching to C and Assembly, i felt back on ASCII output. I would then scroll to find something worth finding. When working with those ASCII output, i had the most success by doing it with two phases. First phase i used a simple fixed sequence to verify that the structures where still coherent at the end of it. +*+*+ +*+*+ +*.*+ This shape was made up, move after moves, and positioned on an edge. Then black plays to capture the two white stones inside the shape, Then white play inside the eye, to capture black then black captures the white stone again. + represent white * represent black Then i would simply make random moves, and verify that all was going well (especially capture detection). usually i deactivated eye-filling-interdiction for this phase. It enable the board to loop a few times. I would then make 1000 moves, and check that everything was fine, even after the board had been wiped out a few time. - WHAT TOOLS DO YOU USE FOR DEBUGGING BOARD IMPLEMENTATIONS ? - _ Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger ! http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] survey : Debuging a board implementation.
unit tests. Except for speed builds, any build of my bot will run every unit test on start up and verify a conforming implementation. game/go.d contains 20 unit tests. Along with a with other design by contact elements, I have a total of 141 assertions. I have the ability to draw the board state during execution, and I've used it occasionally, but I rely on my unit tests. Within the last month, I accidentally broke my eye detection code. I was happy to have my unit tests to pick that up. Here's a portion of my bot's output when I enable reporting of unit tests: Testing goBoardPosition converstions to/from Utf8 Testing goAction conversion to/from Utf8 Testing enumerated move generation Testing board position structures match expectations Testing single stone capture in corner Testing single stone suicide in corner Testing single stone capture on edge Testing single stone suicide on edge Testing single stone capture in center Testing single stone suicide in center Testing simple chain formation Testing simple chain capture Testing liberties after chain capture Testing chain mergers Testing anti-eye-filling rule in corner Testing anti-eye-filling rule on edge Testing anti-eye-filling rule in center Testing positional zorbist hashing Testing situational zorbist hashing On Wed, 2008-10-22 at 11:43 +0200, Denis fidaali wrote: Hi. - WHAT TOOLS DO YOU USE FOR DEBUGGING BOARD IMPLEMENTATIONS ? - - Here is how i do it : - I have made quite a few board implementation in the past years. Initially i used a custom made dirty Java-swing-visualizer. It was very usefull to get started, as we had the goal to reach the 20k simulation/s marks. We used not very user-readable structures, and so it was very helpfull for testing purposes. The java-swing-visualizer enabled me to visualize easily different views on the board-state. Later on, when switching to C and Assembly, i felt back on ASCII output. I would then scroll to find something worth finding. When working with those ASCII output, i had the most success by doing it with two phases. First phase i used a simple fixed sequence to verify that the structures where still coherent at the end of it. +*+*+ +*+*+ +*.*+ This shape was made up, move after moves, and positioned on an edge. Then black plays to capture the two white stones inside the shape, Then white play inside the eye, to capture black then black captures the white stone again. + represent white * represent black Then i would simply make random moves, and verify that all was going well (especially capture detection). usually i deactivated eye-filling-interdiction for this phase. It enable the board to loop a few times. I would then make 1000 moves, and check that everything was fine, even after the board had been wiped out a few time. - WHAT TOOLS DO YOU USE FOR DEBUGGING BOARD IMPLEMENTATIONS ? - _ Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger ! http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] survey : Debuging a board implementation.
I'm using unit-tests also, although somehow for Go programming not nearly as much as I usually do. And I use CruiseControl. It monitors changes in my repository, builds the project and runs the tests. That way I don't have to think about it, it happens automatically. Another thing that I find useful is to make comprehensive implementations of the toString() method. Even if I don't print it on the screen, I can always see it in the debugger, which uses the toString() method to display variable contents. Mark On 22-okt-08, at 10:38, Jason House wrote: unit tests. Except for speed builds, any build of my bot will run every unit test on start up and verify a conforming implementation. game/go.d contains 20 unit tests. Along with a with other design by contact elements, I have a total of 141 assertions. I have the ability to draw the board state during execution, and I've used it occasionally, but I rely on my unit tests. Within the last month, I accidentally broke my eye detection code. I was happy to have my unit tests to pick that up. Here's a portion of my bot's output when I enable reporting of unit tests: Testing goBoardPosition converstions to/from Utf8 Testing goAction conversion to/from Utf8 Testing enumerated move generation Testing board position structures match expectations Testing single stone capture in corner Testing single stone suicide in corner Testing single stone capture on edge Testing single stone suicide on edge Testing single stone capture in center Testing single stone suicide in center Testing simple chain formation Testing simple chain capture Testing liberties after chain capture Testing chain mergers Testing anti-eye-filling rule in corner Testing anti-eye-filling rule on edge Testing anti-eye-filling rule in center Testing positional zorbist hashing Testing situational zorbist hashing On Wed, 2008-10-22 at 11:43 +0200, Denis fidaali wrote: Hi. - - --- WHAT TOOLS DO YOU USE FOR DEBUGGING BOARD IMPLEMENTATIONS ? - - --- - - --- Here is how i do it : - - --- I have made quite a few board implementation in the past years. Initially i used a custom made dirty Java-swing-visualizer. It was very usefull to get started, as we had the goal to reach the 20k simulation/s marks. We used not very user-readable structures, and so it was very helpfull for testing purposes. The java-swing-visualizer enabled me to visualize easily different views on the board-state. Later on, when switching to C and Assembly, i felt back on ASCII output. I would then scroll to find something worth finding. When working with those ASCII output, i had the most success by doing it with two phases. First phase i used a simple fixed sequence to verify that the structures where still coherent at the end of it. +*+*+ +*+*+ +*.*+ This shape was made up, move after moves, and positioned on an edge. Then black plays to capture the two white stones inside the shape, Then white play inside the eye, to capture black then black captures the white stone again. + represent white * represent black Then i would simply make random moves, and verify that all was going well (especially capture detection). usually i deactivated eye-filling-interdiction for this phase. It enable the board to loop a few times. I would then make 1000 moves, and check that everything was fine, even after the board had been wiped out a few time. - - --- WHAT TOOLS DO YOU USE FOR DEBUGGING BOARD IMPLEMENTATIONS ? - - --- _ Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger ! http://www.ilovemessenger.fr/Emoticones/ EmoticonesDejantees.aspx_ __ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] survey : Debuging a board implementation.
I have many assertions, but no unit tests. When I use incremental data structures I have code to in the debug build to calculate the same results non-incrementally, and assert if they dont compare. David -Original Message- From: [EMAIL PROTECTED] [mailto:computer-go- [EMAIL PROTECTED] On Behalf Of Denis fidaali Sent: Wednesday, October 22, 2008 2:43 AM To: computer-go@computer-go.org Subject: [computer-go] survey : Debuging a board implementation. Hi. --- --- --- WHAT TOOLS DO YOU USE FOR DEBUGGING BOARD IMPLEMENTATIONS ? --- --- --- --- --- --- Here is how i do it : --- --- --- I have made quite a few board implementation in the past years. Initially i used a custom made dirty Java-swing-visualizer. It was very usefull to get started, as we had the goal to reach the 20k simulation/s marks. We used not very user-readable structures, and so it was very helpfull for testing purposes. The java-swing-visualizer enabled me to visualize easily different views on the board-state. Later on, when switching to C and Assembly, i felt back on ASCII output. I would then scroll to find something worth finding. When working with those ASCII output, i had the most success by doing it with two phases. First phase i used a simple fixed sequence to verify that the structures where still coherent at the end of it. +*+*+ +*+*+ +*.*+ This shape was made up, move after moves, and positioned on an edge. Then black plays to capture the two white stones inside the shape, Then white play inside the eye, to capture black then black captures the white stone again. + represent white * represent black Then i would simply make random moves, and verify that all was going well (especially capture detection). usually i deactivated eye-filling-interdiction for this phase. It enable the board to loop a few times. I would then make 1000 moves, and check that everything was fine, even after the board had been wiped out a few time. --- --- --- WHAT TOOLS DO YOU USE FOR DEBUGGING BOARD IMPLEMENTATIONS ? --- --- --- _ Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger ! http://www.ilovemessenger.fr/Emoticones/EmoticonesDejantees.aspx___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] survey : Debuging a board implementation.
I use JUnit unit tests. Peter Drake http://www.lclark.edu/~drake/ On Oct 22, 2008, at 6:09 AM, Mark Boon wrote: I'm using unit-tests also, although somehow for Go programming not nearly as much as I usually do. And I use CruiseControl. It monitors changes in my repository, builds the project and runs the tests. That way I don't have to think about it, it happens automatically. Another thing that I find useful is to make comprehensive implementations of the toString() method. Even if I don't print it on the screen, I can always see it in the debugger, which uses the toString() method to display variable contents. Mark On 22-okt-08, at 10:38, Jason House wrote: unit tests. Except for speed builds, any build of my bot will run every unit test on start up and verify a conforming implementation. game/go.d contains 20 unit tests. Along with a with other design by contact elements, I have a total of 141 assertions. I have the ability to draw the board state during execution, and I've used it occasionally, but I rely on my unit tests. Within the last month, I accidentally broke my eye detection code. I was happy to have my unit tests to pick that up. Here's a portion of my bot's output when I enable reporting of unit tests: Testing goBoardPosition converstions to/from Utf8 Testing goAction conversion to/from Utf8 Testing enumerated move generation Testing board position structures match expectations Testing single stone capture in corner Testing single stone suicide in corner Testing single stone capture on edge Testing single stone suicide on edge Testing single stone capture in center Testing single stone suicide in center Testing simple chain formation Testing simple chain capture Testing liberties after chain capture Testing chain mergers Testing anti-eye-filling rule in corner Testing anti-eye-filling rule on edge Testing anti-eye-filling rule in center Testing positional zorbist hashing Testing situational zorbist hashing On Wed, 2008-10-22 at 11:43 +0200, Denis fidaali wrote: Hi. - WHAT TOOLS DO YOU USE FOR DEBUGGING BOARD IMPLEMENTATIONS ? - - Here is how i do it : - I have made quite a few board implementation in the past years. Initially i used a custom made dirty Java-swing-visualizer. It was very usefull to get started, as we had the goal to reach the 20k simulation/s marks. We used not very user-readable structures, and so it was very helpfull for testing purposes. The java-swing-visualizer enabled me to visualize easily different views on the board-state. Later on, when switching to C and Assembly, i felt back on ASCII output. I would then scroll to find something worth finding. When working with those ASCII output, i had the most success by doing it with two phases. First phase i used a simple fixed sequence to verify that the structures where still coherent at the end of it. +*+*+ +*+*+ +*.*+ This shape was made up, move after moves, and positioned on an edge. Then black plays to capture the two white stones inside the shape, Then white play inside the eye, to capture black then black captures the white stone again. + represent white * represent black Then i would simply make random moves, and verify that all was going well (especially capture detection). usually i deactivated eye-filling-interdiction for this phase. It enable the board to loop a few times. I would then make 1000 moves, and check that everything was fine, even after the board had been wiped out a few time. - WHAT TOOLS DO YOU USE FOR DEBUGGING BOARD IMPLEMENTATIONS ? - _ Inédit ! Des Emoticônes Déjantées! Installez les dans votre Messenger ! http://www.ilovemessenger.fr/Emoticones/ EmoticonesDejantees.aspx ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list
