As I stated in the previous post: I have looked through the code several times, and I cannot spot the problem. I think it may be a logical error, but as far as I can tell, there is none. Seeing as I am not in a c++ class and do not have anyone else to refer to (I ran this by my friend and he didn't spot any errors either),
That's the problem. Very few human beings can "spot" errors without debugging the program, unless the error is so glaringly obvious. There are too many loops, variables, paths the code can take, etc. to make it even possible for anything but an extraordinary human being to try and figure out "by sight".
A trained programmer can look at just a few lines of code that they did not write (around 50, if that many) and tell if there is something logically wrong with it. If you're attempting to just "look" at the code and spot logical errors without stepping through the code, then you're better than most of the programmers that I know.
Programmers used to "hand debug", where they would step through the code with pencil and paper. This worked somewhat, but it is still error prone, as again, we're mere human beings -- we get tired, lose our place in the code, forget to write down stuff, etc. That's why interactive debuggers were developed, so as to eliminate the possiblity of these things happening when debugging a program.
will anyone give me some suggestions as to how to go about debugging this, or tell me if there is a logical error in my method of solving?
We did. Single step through the program.
Again, you wrote the program, therefore you should know exactly what each step, loop, assignment, etc. is supposed to do at every step of execution. You know what is supposed to go in as input, and what is supposed to come out at the other end as the result, and hopefully you wrote the code using these suppositions. Now that you wrote the code and it is not doing what you want it to do, you inspect where the program starts to break down.
"What happens after this loop I wrote? Are the values correct? What is the value of this variable? It was supposed to be x, but it's y. It must be this loop -- yep, there is the problem". These are the questions that you should be asking yourself when debugging a program.
Again: the program does not crash, but it never passes the last if statement of "if(correctnum==true)" even when I know there are several places on the grid where it should.
So now you know the end result, run the debugger and see why that last if() statement is not true.
Also, instead of telling us what to cut, paste, copy, etc. to get a working program, post the entire program that you are now using. It is less likely to have issues if we get the code from you without having to edit anything.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; May 14th, 2009 at 04:09 AM.
And when you step through it with a debugger, note that lines like this:
Code:
if (x = true)
will always set x to true.
This is a very common type of mistake. If you write
Code:
if (true == x)
then you will get a compiler error if you accidentally leave out the second equals.
Alan
Supa, please take note of this post I've quoted above, it contains the answer to your problem regarding the nested for loops always returning false. The code you posted contains the following lines
I found that, after I fixed the syntax error (blame Game Maker for that one, they allow you to do something like "if(x=2)" in their scripting), the function almost works correctly. To be more specific, the horizontal and vertical checks work fine, but not the square check. I know this because I did 3 things:
1. I did the sudoku by hand to find what numbers go where.
2. I used 'dispothermatrix()' to look at smatrix, and I did by hand what I want the program to do (I myself looked at rows, columns, and boxes, to find 0s that were standing alone) and I found that all of these were the correct numbers as checked by the sudoku I had completed.
3. Within 'if (correctnum==true)' I added something that would tell me the coordinates and the numbers of the spots that passed the tests, and which test it passed (horizontal, vertical, or square). Some of these matched my hand-solved sudoku, some didn't. I found that the ones that did match were the ones that passed either the horizontal or the vertical tests, and the ones that didn't match were the ones that passed the square test.
Thus, my problem should be in the square test. However, as far as checking every spot in the square, the programming is exactly the same as the one to set smatrix, which works fine. Also, as far as the test, it is the same as the horizontal and vertical tests.
The code to set the squares in smatrix (working)
Code:
int cx=x-((x-1)%3),
cy=y-((y-1)%3);
for(int e=0;e<3;e++)
for(int i=0;i<3;i++)
smatrix[cx+e][cy+i][currentnum]=1;
What is the value of cx, cy, and z when those lines are executed? What is the value of that position in the matrix? What do you expect them to be? What are their actual values when you debug the program?
Also on a side note, one and two letter variable names such as "e", "z" "cx", etc. makes the program harder to understand and to debug, making it more prohibitive for anyone to help. Make your variables have meaningful names so that even you will understand what they are supposed to denote when you look at your program 6 months from now.
I'm glad you found a solution to some of your problems. However, the issue stays the same -- you need to carefully debug the program using the debugger -- it still sounds like you're just writing something, and then hoping that it works. You wrote that loop expecting some values, but you didn't state anything about what values you're getting there, or your observations as to what is wrong in that loop.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; May 14th, 2009 at 06:11 PM.
I think this is because I was never completely clear with myself about which direction was x and which was y. I will make sure not to do THAT again...
Anyways, thanks Paul. I'm glad I found this and not someone else. By the way, did you know this was the problem all along? If so, thanks for not saying it, and if not...whatever.
If anyone wants to see the working program, simply make the change I have indicated (it is on line 322).
Also, I have serious doubts about programs such as yours that assume that arrays start at index 1 in C++.
In C++, arrays start at index 0, and you are to assume that the first position is index 0, not 1. By writing a program that assumes that the first position is index 1, you open yourself up for memory overwrite bugs, and other hard to diagnose problems.
I've been doing this a long time, and more often than not, any program that I've seen written that assumes or tries to fake out C++ into starting arrays at index 1 instead of 0 always ends up with some sort of indexing bug.
Maybe, but read my last post very carefully. Make sure you really are within bounds of your arrays, and not indexing one to many. Again, these are the perils of trying to simulate C++ arrays starting at index 1.
My problem was not with indexing, it was with switching x and y. If you notice in how I fixed the problem, I had to make the test if (cx==y...). There was no problem with the array indexes; if you note a previous post I made, I was uniform with my 'mistake' as to arrays, thus it was not my problem. Had my loops, arrays, etc. started at 0 instead of 1, I would have faced the same problem. The reason I had the arrays start at 1 was for my own conceptualizing purposes, so it would be easier to write the program. The next step for me now is to rewrite the program, condensing and cleaning up, for example making the arrays start at 0 instead of 1.
I was unaware of the potential problems you listed, but I did know that it is not ideal to have the arrays how I have them now, and I was planning on changing it before you said anything.
Last edited by supahamster; May 15th, 2009 at 01:12 AM.
Had my loops, arrays, etc. started at 0 instead of 1, I would have faced the same problem. The reason I had the arrays start at 1 was for my own conceptualizing purposes, so it would be easier to write the program.
The problem I am speaking of has nothing to do with the logic of the program. It has everything to do with overwriting the boundaries of an array. If you have an array declared as this:
Code:
int x[10];
And then you base a lot of code starting with the array index at 1, this may or may not work, regardless of how flawless the logic may be:
Code:
for (int i = 1; i <=10; ++i )
x[i] = 0;
This code can seem to "work", or it can crash as soon as i becomes 10 and "x[i] = 0" is executed. This is a simple error, but pretend if it wasn't just "10", but some computed value in that loop that becomes hard to spot by sight.
This is exactly how assuming indices starting at 1 cause problems. You are fooled into thinking "finally the program works", but really, it is on shaky ground due to the memory access violation, not because of a flaw in the logic.
In C++, this is called undefined behaviour.
Regards,
Paul McKenzie
Last edited by Paul McKenzie; May 15th, 2009 at 07:14 AM.
This can only be a problem, however, if the matrix is declared one way and then you try to access outside of its declaration. As you may notice, my declarations are currently
Code:
matrix[10][10]
When they only need to be 9x9. Thus, I have accounted for the possibility of a program crash because of this, and avoided it. Also, as I said earlier, I plan to clean this up, which includes making everything 0-based. What I was worrying about was the logic of the program, not optimizing it or anything else. When debugging, I find it easier to be able to skip the step of adding 1 in my head. For example in a 0-based system, the point (1,2) will actually be (2,3) on the visual board. Thus, I made it 1-based so that I could see more quickly what was where, and to work out the logic more easily.
However, why would the program be on shaky ground? All I am really doing is creating a matrix that is slightly larger than I need, and ignoring some of the values. Since everything is declared to accommodate the shift, I see no reason why this is more shaky than otherwise.
However, I do understand that it would be preferable to change for various reasons and I plan to do so.
* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.
Originally Posted by supahamster
Reply With Quote
