AppletTalk.com Java discussions newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Noughts and Crosses game Goto page 1, 2  Next          AppletTalk.com Forum Index -> Java Help View previous topic :: View next topic   Author Message michael_jd Guest Posted: Sat May 19, 2007 6:38 am    Post subject: Noughts and Crosses game My noughts and crosses game should stop you from playing on the same square twice, however it doesn't and a don't have a clue why. Here's the code. public class NoughtsAndCrosses { static final int EMPTY = 0, NOUGHT = 1, CROSS = 2; private int[][] board; int numPlays; int winner; int player; public NoughtsAndCrosses() { board = new int[3][3]; for(int row = 0; row < 3; row++) { for(int column = 0; column < 3; column++) { board[row][column] = EMPTY; } } player = CROSS; numPlays = 0; winner = 0; } //these are the methods that check if you have played at a square already public void crossPlaysAt(int row, int column) { if(player == CROSS) { if(board[row][column] != CROSS || board[row][column] != NOUGHT) { board[row][column] = CROSS; numPlays++; checkState(); player = NOUGHT; } else { System.out.println("Square already occupied"); } } else { System.out.println("This is not cross' turn; allow nought to play"); } } public void noughtPlaysAt(int row, int column) { if(player == NOUGHT) { if(board[row][column] != CROSS || board[row][column] != NOUGHT) { board[row][column] = NOUGHT; numPlays++; checkState(); player = CROSS; } else { System.out.println("Square already occupied"); } } else { System.out.println("This is not nought's turn; allow cross to play"); } } private void checkState() { winner = 0; for(int row = 0; row < 3; row++) { checkForWin(new int[] {board[row][0], board[row][1], board[row][2]}); } for(int col = 0; col < 3; col++) { checkForWin(new int[] {board[0][col], board[1] [col],board[2][col]}); } checkForWin(new int[] {board[0][0], board[1][1], board[2] [2]}); checkForWin(new int[] {board[0][2], board[1][1], board[2] [0]}); if(winner == NOUGHT) { System.out.println("Nought wins!!!"); } if(winner == CROSS) { System.out.println("Cross wins!!!"); } if(numPlays == 9) { System.out.println("Drawn game"); } } private void checkForWin(int[] squares) { if(squares[0] == squares[1] && squares[0] == squares[2] && squares[0] != EMPTY) { winner = squares[0]; } } } Thanks for the help guys! Back to top Patricia Shanahan Guest Posted: Sat May 19, 2007 7:06 am    Post subject: Re: Noughts and Crosses game michael_jd wrote: Quote: My noughts and crosses game should stop you from playing on the same square twice, however it doesn't and a don't have a clue why. Here's the code. .... static final int EMPTY = 0, NOUGHT = 1, CROSS = 2; .... if(board[row][column] != CROSS || board[row][column] != NOUGHT) This condition is always true. Patricia Back to top Chris Smith Guest Posted: Sat May 19, 2007 7:11 am    Post subject: Re: Noughts and Crosses game Patricia Shanahan <pats (AT) acm (DOT) org> wrote: Quote: I very strongly disapprove of rejecting bug reports just because they cannot be reproduced. However, I have seen it done far too often. Hmm. I disagree with it as a matter of policy, certainly. In practice, though, when one is faced with a large number of bugs and very little time, it is often sensible to fix only those that are reproducible; they are, after all, already half done. I have also taken the stance, in the past, that bugs that aren't reproducible belong in the customer relations space rather than the development space, and fought to keep them out of bug tracking systems. This had a lot to do with my level of distrust for our support people, though. And even then, I would have disagreed loudly had someone proposed that we not track them at all. -- Chris Smith Back to top printdude1968@gmail.com Guest Posted: Sat May 19, 2007 7:11 am    Post subject: Re: Noughts and Crosses game On May 18, 10:06 pm, Patricia Shanahan <p...@acm.org> wrote: Quote: michael_jd wrote: My noughts and crosses game should stop you from playing on the same square twice, however it doesn't and a don't have a clue why. Here's the code. ... static final int EMPTY = 0, NOUGHT = 1, CROSS = 2; ... if(board[row][column] != CROSS || board[row][column] != NOUGHT) This condition is always true. Patricia Patricia, Were you able to spot that just by looking at it, or did you do some sort of debugging on it? I would have set up breakpoints in my IDE and examined variable values. Is that the process you went through for this particular problem? Back to top Patricia Shanahan Guest Posted: Sat May 19, 2007 7:11 am    Post subject: Re: Noughts and Crosses game printdude1968 (AT) gmail (DOT) com wrote: Quote: On May 18, 10:33 pm, Patricia Shanahan <p...@acm.org> wrote: http://home.earthlink.net/~patricia_shanahan/debug Very nice but do you think that "The simplest and easiest approach, at least in the short term, is denial. Refuse to debug unless the user can provide a test case that reliably reproduces the bug. Reject bug reports with "unable to reproduce". This approach is very popular, except with people who have to use the programs." would be accepted by someone calling a help desk and wanting help? The reason I ask is, that while I agree 100% with this approach, in my job as a tech support person, I would be hung out to dry if I told my customers that I was not able to take on their issues because they couldn't reproduce the problem. I very strongly disapprove of rejecting bug reports just because they cannot be reproduced. However, I have seen it done far too often. Patricia Back to top printdude1968@gmail.com Guest Posted: Sat May 19, 2007 7:11 am    Post subject: Re: Noughts and Crosses game On May 18, 10:33 pm, Patricia Shanahan <p...@acm.org> wrote: Quote: http://home.earthlink.net/~patricia_shanahan/debug Very nice but do you think that "The simplest and easiest approach, at least in the short term, is denial. Refuse to debug unless the user can provide a test case that reliably reproduces the bug. Reject bug reports with "unable to reproduce". This approach is very popular, except with people who have to use the programs." would be accepted by someone calling a help desk and wanting help? The reason I ask is, that while I agree 100% with this approach, in my job as a tech support person, I would be hung out to dry if I told my customers that I was not able to take on their issues because they couldn't reproduce the problem. Back to top Patricia Shanahan Guest Posted: Sat May 19, 2007 7:11 am    Post subject: Re: Noughts and Crosses game printdude1968 (AT) gmail (DOT) com wrote: Quote: On May 18, 10:06 pm, Patricia Shanahan <p...@acm.org> wrote: michael_jd wrote: My noughts and crosses game should stop you from playing on the same square twice, however it doesn't and a don't have a clue why. Here's the code. ... static final int EMPTY = 0, NOUGHT = 1, CROSS = 2; ... if(board[row][column] != CROSS || board[row][column] != NOUGHT) This condition is always true. Patricia Patricia, Were you able to spot that just by looking at it, or did you do some sort of debugging on it? I would have set up breakpoints in my IDE and examined variable values. Is that the process you went through for this particular problem? I spotted it just by looking at it. However, I agree that debug cannot depend on instant spotting of the error. It is not guaranteed to work. See http://home.earthlink.net/~patricia_shanahan/debug/ for my views on a more reliable approach. Patricia Back to top Greg R. Broderick Guest Posted: Sat May 19, 2007 1:19 pm    Post subject: Re: Noughts and Crosses game "printdude1968 (AT) gmail (DOT) com" <printdude1968 (AT) gmail (DOT) com> wrote in news:1179542764.131713.177460 (AT) u30g2000hsc (DOT) googlegroups.com: Quote: would be accepted by someone calling a help desk and wanting help? The reason I ask is, that while I agree 100% with this approach, in my job as a tech support person, I would be hung out to dry if I told my customers that I was not able to take on their issues because they couldn't reproduce the problem. IMO, part of your job as a technical support person is to gather enough information from the client so that _you_ can reproduce the issue. You can then document the issue, and how you reproduced it, in your report to your developers. That's how it worked when I did tech support -- bugs that couldn't get reproduced didn't get passed up to the developers, but the support rep continued eliciting more information from the customer until the issue was reproducible. Cheers! -- --------------------------------------------------------------------- Greg R. Broderick usenet200705 (AT) blackholio (DOT) dyndns.org A. Top posters. Q. What is the most annoying thing on Usenet? --------------------------------------------------------------------- Back to top Patricia Shanahan Guest Posted: Sat May 19, 2007 6:13 pm    Post subject: Re: Noughts and Crosses game Chris Smith wrote: Quote: Patricia Shanahan <pats (AT) acm (DOT) org> wrote: I very strongly disapprove of rejecting bug reports just because they cannot be reproduced. However, I have seen it done far too often. Hmm. I disagree with it as a matter of policy, certainly. In practice, though, when one is faced with a large number of bugs and very little time, it is often sensible to fix only those that are reproducible; they are, after all, already half done. I have also taken the stance, in the past, that bugs that aren't reproducible belong in the customer relations space rather than the development space, and fought to keep them out of bug tracking systems. This had a lot to do with my level of distrust for our support people, though. And even then, I would have disagreed loudly had someone proposed that we not track them at all. If the difficult to reproduce bugs are excluded from the bug tracking, how do track them well enough to detect the patterns that could lead to a solution? Patricia Back to top Patricia Shanahan Guest Posted: Sat May 19, 2007 6:18 pm    Post subject: Re: Noughts and Crosses game Greg R. Broderick wrote: Quote: "printdude1968 (AT) gmail (DOT) com" <printdude1968 (AT) gmail (DOT) com> wrote in news:1179542764.131713.177460 (AT) u30g2000hsc (DOT) googlegroups.com: would be accepted by someone calling a help desk and wanting help? The reason I ask is, that while I agree 100% with this approach, in my job as a tech support person, I would be hung out to dry if I told my customers that I was not able to take on their issues because they couldn't reproduce the problem. IMO, part of your job as a technical support person is to gather enough information from the client so that _you_ can reproduce the issue. You can then document the issue, and how you reproduced it, in your report to your developers. That's how it worked when I did tech support -- bugs that couldn't get reproduced didn't get passed up to the developers, but the support rep continued eliciting more information from the customer until the issue was reproducible. What about timing dependent bugs that happen once every few days? I've seen bugs that, even given the right workloads, only happened with just the right timing between several parallel activities. Admittedly, my worst experiences along that line involved multiprocessor servers, where many threads could really run at the same time, but the trend is towards hardware multithreading, multiple cores in each processor chip, and multiple processor chips on each motherboard. Patricia Back to top printdude1968@gmail.com Guest Posted: Sat May 19, 2007 6:24 pm    Post subject: Re: Noughts and Crosses game On May 19, 5:19 am, "Greg R. Broderick" <usenet200...@blackholio.dyndns.org> wrote: Quote: "printdude1...@gmail.com" <printdude1...@gmail.com> wrote innews:1179542764.131713.177460 (AT) u30g2000hsc (DOT) googlegroups.com: would be accepted by someone calling a help desk and wanting help? The reason I ask is, that while I agree 100% with this approach, in my job as a tech support person, I would be hung out to dry if I told my customers that I was not able to take on their issues because they couldn't reproduce the problem. IMO, part of your job as a technical support person is to gather enough information from the client so that _you_ can reproduce the issue. You can then document the issue, and how you reproduced it, in your report to your developers. That's how it worked when I did tech support -- bugs that couldn't get reproduced didn't get passed up to the developers, but the support rep continued eliciting more information from the customer until the issue was reproducible. Cheers! -- --------------------------------------------------------------------- Greg R. Broderick usenet200...@blackholio.dyndns.org A. Top posters. Q. What is the most annoying thing on Usenet? --------------------------------------------------------------------- The "stuff" we support are third-party software products so the information we have to gather is usually to either fix the problem ourselves, or escalate to the vendor support group. There are some internal products (home grown apps) that require a higher level of technical expertese than what is available in the programmer teams so we get involved there as well, especially when the problem can be traced not to the app, but to the OS. Back to top printdude1968@gmail.com Guest Posted: Sat May 19, 2007 6:26 pm    Post subject: Re: Noughts and Crosses game On May 19, 10:18 am, Patricia Shanahan <p...@acm.org> wrote: Quote: Greg R. Broderick wrote: "printdude1...@gmail.com" <printdude1...@gmail.com> wrote in news:1179542764.131713.177460 (AT) u30g2000hsc (DOT) googlegroups.com: would be accepted by someone calling a help desk and wanting help? The reason I ask is, that while I agree 100% with this approach, in my job as a tech support person, I would be hung out to dry if I told my customers that I was not able to take on their issues because they couldn't reproduce the problem. IMO, part of your job as a technical support person is to gather enough information from the client so that _you_ can reproduce the issue. You can then document the issue, and how you reproduced it, in your report to your developers. That's how it worked when I did tech support -- bugs that couldn't get reproduced didn't get passed up to the developers, but the support rep continued eliciting more information from the customer until the issue was reproducible. What about timing dependent bugs that happen once every few days? I've seen bugs that, even given the right workloads, only happened with just the right timing between several parallel activities. Admittedly, my worst experiences along that line involved multiprocessor servers, where many threads could really run at the same time, but the trend is towards hardware multithreading, multiple cores in each processor chip, and multiple processor chips on each motherboard. Patricia Here's a good one... "log off, reboot and the problem goes away". Seriously, a good 60-75% of the issues I see can be solved this way. Those are the easiest to solve, but figuring why it works is often a long process. Back to top printdude1968@gmail.com Guest Posted: Sat May 19, 2007 6:27 pm    Post subject: Re: Noughts and Crosses game On May 19, 10:13 am, Patricia Shanahan <p...@acm.org> wrote: Quote: Chris Smith wrote: Patricia Shanahan <p...@acm.org> wrote: I very strongly disapprove of rejecting bug reports just because they cannot be reproduced. However, I have seen it done far too often. Hmm. I disagree with it as a matter of policy, certainly. In practice, though, when one is faced with a large number of bugs and very little time, it is often sensible to fix only those that are reproducible; they are, after all, already half done. I have also taken the stance, in the past, that bugs that aren't reproducible belong in the customer relations space rather than the development space, and fought to keep them out of bug tracking systems. This had a lot to do with my level of distrust for our support people, though. And even then, I would have disagreed loudly had someone proposed that we not track them at all. If the difficult to reproduce bugs are excluded from the bug tracking, how do track them well enough to detect the patterns that could lead to a solution? Patricia Document everything... Back to top Lew Guest Posted: Sat May 19, 2007 6:55 pm    Post subject: Re: Noughts and Crosses game printdude1968 (AT) gmail (DOT) com wrote: Quote: The "stuff" we support are third-party software products so the information we have to gather is usually to either fix the problem ourselves, or escalate to the vendor support group. There are some internal products (home grown apps) that require a higher level of technical expertese than what is available in the programmer teams so we get involved there as well, especially when the problem can be traced not to the app, but to the OS. Having spent years of my career in technical support for non-technical people, most of it on products not made by my employers, I conclude that there is only one fair principle in tech support: Be totally committed to resolution of the customer's difficulty. It also has little to do with debugging - debugging is a programmer activity, not a customer-support activity, although of course it can be in service of support. As far as the OP's problem goes, it was one of those that leapt out at me as I looked at the code. No debugging necessary. The type of thing that shows up in code reviews. -- Lew Back to top Patricia Shanahan Guest Posted: Sat May 19, 2007 7:24 pm    Post subject: Re: Noughts and Crosses game printdude1968 (AT) gmail (DOT) com wrote: Quote: On May 19, 10:18 am, Patricia Shanahan <p...@acm.org> wrote: Greg R. Broderick wrote: "printdude1...@gmail.com" <printdude1...@gmail.com> wrote in news:1179542764.131713.177460 (AT) u30g2000hsc (DOT) googlegroups.com: would be accepted by someone calling a help desk and wanting help? The reason I ask is, that while I agree 100% with this approach, in my job as a tech support person, I would be hung out to dry if I told my customers that I was not able to take on their issues because they couldn't reproduce the problem. IMO, part of your job as a technical support person is to gather enough information from the client so that _you_ can reproduce the issue. You can then document the issue, and how you reproduced it, in your report to your developers. That's how it worked when I did tech support -- bugs that couldn't get reproduced didn't get passed up to the developers, but the support rep continued eliciting more information from the customer until the issue was reproducible. What about timing dependent bugs that happen once every few days? I've seen bugs that, even given the right workloads, only happened with just the right timing between several parallel activities. Admittedly, my worst experiences along that line involved multiprocessor servers, where many threads could really run at the same time, but the trend is towards hardware multithreading, multiple cores in each processor chip, and multiple processor chips on each motherboard. Patricia Here's a good one... "log off, reboot and the problem goes away". Seriously, a good 60-75% of the issues I see can be solved this way. Those are the easiest to solve, but figuring why it works is often a long process. I think that is the only technique I learned during the first week on my first programming job, in 1970, that is still state-of-the-art today. However, it is a bug avoidance technique, not a solution. Especially for production servers, there is a limit to how often a reasonable user will be willing to have the machine down for a reboot, especially an unscheduled reboot at an arbitrary time, often at a particularly busy time, because those are the most likely times for certain types of timing bugs. Patricia Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         AppletTalk.com Forum Index -> Java Help All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum Java Newsgroups----------------Java DiscussionsWeb-based java games comp.lang.java 3D Graphics API's for Java Java: Support and criticism Java System Announcements comp.lang.java.api JavaBeans Java and CORBA Java and Databases comp.lang.java.developer Java GUI Toolkits Java Help comp.lang.java.javascript JVM, native methods and hardware comp.lang.java.misc Java Language Programming Security and Java comp.lang.java.setup Java Software Tools comp.lang.java.tech ibm.software.java.linux  Non-English Java Newsgroups----------------Java Language (German)Language Java (Français)Java (Italian)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.