It isn't so much predicting what the program is likely to do, but rather it is understanding the current state of the machine and how that affects the next state of the machine, which lets you follow each state, or step.

And the thing about generic algorithms is that they are not specifically computing concepts - they are really just methods of breaking down a larger problem into a more easily described set of smaller steps (or states) which lead to a desired end state when performed in sequence.

For example, walking around the block can be described as an algorithm (assumes you live on a square block):

You could also show this as a Flow Chart in which each step between Start and Done is represented as a square with its action written inside, and each square connected by a line, or "flow", with an arrow showing the direction of flow from one state (corner) to the next.

You already think of some things algorithmically, but you are trying to learn programming as "code" and are not thinking of programs as algorithms, which is blocking you from understanding what they are doing.

Your LQ signature expresses a couple of algorithms, even though you do not think of them as such:

The main point here is to get you to begin thinking of what a program does, or what you want it to do as an algorithm first, and only as code after you can walk around the algorithm clearly in your head, or on paper, or in a drawing program such as Umlet!

Thinking algorithmically is a skill most of us learn during our math education, and the exercise which most strongly builds that skill is the "word problem" most of us came to dread. Word problems require us to visualize some problem in our heads, break it into a sequence of operations which lead to some desired end state, or answer, then step through those operations to get the actual answer.

You actually are capable of thinking algorithmically as indicated by the above examples! But you seem to have never developed the skill as a formal system of thought, probably due to the missing math exercises. So the way to build that skill is still the same - begin to exercise it, work the "word problems"!

Think of the things you do through the day as algorithms - sequences of smaller steps which perform some larger task. And visualize those steps in your mind, express them as words and draw them as little boxes connected by lines! Walk around those diagrams with pencil and paper or some drawing program and train your brain to do that automatically.

Programming is just that same exercise - we must visualize the thing we want to do beginning from some initial state, and ending with some desired final state, then work out a set of steps (the algorithm) which will accomplish it. Only after we have described the algorithm and can verify in our heads that it will indeed accomplish the desired task do we then implement it in the code syntax of some programming language.

Similarly, to understand what some program is doing we must reverse the process by writing out the algorithm, the set of steps the code expresses and follow the algorithm, not necessarily the code, in our heads.

So my point again is this: Build on what you have, your existing ability to think algorithmically for non-programming tasks, and extend it into all your daily activities. Learn it as a way of thinking about things, not as "code". Exercise it and learn the simple notations which allow you to put it on paper, and into words, and ultimately into the syntax of a programming language!

Good luck!

1 members found this post helpful.

I agree with the continued points by Astrogeek, GazL, and others.I feel you should, and shouldn't be predicting what it "is likely" to do next.

When you code something, you should be predicting what is going to happen next.

When you are debugging, you should be no longer predicting and instead finding where it had a problem.

While debugging it is fine to have an expectation as to what "should" happen next, but it is important to actually "see and experience" what does happen next.

If there is a difference between what you expected and what happened THAT is the definition of a bug.

Your post of using GDB and debug outputting an array is 100% correct.

Perhaps you don't see the point of that exercise because it doesn't show you any problem or teach you specifically how to fix something.

The point of that exercise was so that you could see how to inspect the data and examples of how it would appear.

Given this knowledge you can do things like single step through the loop, look at the array, look at the value of the loop counter, which is also the array offset, telling you which specific point in the array you are currently considering when you test things like content[i] against a value, like # or \0.

And this is where you switch between predicting versus not predicting.

Predicting here means that you are in the loop, the loop counter is "some value" (from 0 to max - whatever you defined that to be). Say it goes from 0 to 128. And also say, it is at 55.

When stopped in the debugger, you know that you can inspect variables, such as i, and content[i].
If i is 55 (per my example comment above), then you can use the debugger to look specifically at content[55].
Assuming there's a character there, you'll see what it is by inspecting in the debugger.
At that point you can predict what the program is going to do next.

But now you stop predicting and use the debugger to actually see what does happen next.
Most of us single step and watch the flow of what is happening.
At some point, you typically see a flaw, such as something like where earlier it was looking at a SPACE character, which has the value of 32 and you were at loop counter 32. Hence an earlier bug.
Or you could notice that i has the value of 523, which would be far beyond the limit of the content[] array. Maybe you don't know what exactly happened, but you can see a problem, so you can run it again and try to follow the loop one iteration at a time until you can figure out how the loop counter got beyond where it should have.
These are just examples, but they are examples about how to diagnose a problem.

Once again, when there is a problem, any predictions are only relevant to the limit that you should be predicting what "should" happen, but then using the debugger to determine exactly "what does" happen.

If this is beyond comprehension, then it is. I can't allay that situation any more.

I'm not sure this part has much to do with math. Perhaps logic.

Meanwhile I'm not trying to teach design, at this point. The whole problem here, for this thread, was flawed code which needed debug. As always, the code continued to evolve, and I fully do agree that this is a design approach problem. What I mean when I say that is (probably in agreement with Astrogeek's mindset), you are coding "on the fly", you're sitting there coding away without sketching out an organized approach, or even summarizing your requirements in advance.

Same thing, can't help much there. It has been said that when approaching a new problem, you write down your test and acceptance criteria and you write down a representation of what your algorithm should do.

You don't do that, likely you will end up with bugs, as well as what we call spaghetti, as in spaghetti code which is hard to read and difficult to follow.

3 members found this post helpful.

A little interrupt in debugging might do good: https://www.google.com/doodles/celeb...of-kids-coding

Thanks again guys.

I have watched several of the videos GazL linked earlier on, but I've not watched all of them yet. I'm still yet to learn Umlet, as I've had some other things I've had to do, so life always tends to get in the way - but I will try and learn it. I'll also try practicing algorithms like you suggested astrogeek - writing the steps for something on paper and/or in a text editor to try and get used to them without trying to code it as well.

In relation to the videos GazL linked; I didn't realize you don't have to use a variable as the second argument to printf, like for example do something like printf("%i", 1234); - I thought you had to put a variable where the "1234" is. And while I get what typecasting means and does; I'm not sure what the guy is saying when he's talking about having something like (double) (var / 12) verses (double) var / 12 in the "typecasting video" ? Other than the former doesn't give the correct result because of the parenthesis around the "var / 12".

Anyhow, like I said above, I'll try what ya's said above. Thanks again.

Just take it on faith. It will make more sense to you after you've got to video "36 - Operator precedence".

edit: actually, looking at that playlist the type-casting videos come after that one. If you've been skipping them, then I encourage you not to (except perhaps the how to use vim ones).

While I was thinking about skipping the vim videos, I haven't skipped any of the others - but I might watch the vim videos anyway. Since my vim skills could be improved - I do know a little about using it, but I'm by no means any "expert" on it.

It was what he was talking about in the "C Basics Part 5" video about 5 mins into it that I didn't get - I figured it had something to do with the "precedence" (as I know each C operator has a "precedence" associated with it - I remembered that from the C book/pdf I read before), but it's the maths behind what he was saying that I was talking about (that I don't get).

I'm somewhat tempted to suggest to you a new project, despite having been reprimanded by you before for not helping you directly (in some other thread) and instead suggesting other things...buuuuut...
Maybe it's still a good idea to suggest the following to you, even if it's just a thought exercise.

Writing your own virtual machine/CPU, which is actually easier than it might sound.

It would be just as confusing and difficult as this (only a lot more of it), but with a much better payoff that elevates you into the skies when it clicks in the end.

Okay, it would probably be a lot more confusing as this, but once you understood how CPUs work, C should become easier by ...I dont even know, many many magnitudes or some other probably unfitting measure.

Maybe you should consider this challenge some day, to start you off:
Your standard (Turing complete) processing unit requires a few core instructions.
It must be able to read and write to memory locations.
It must have conditional branching, as in, the ability to test values and jump somewhere else in the instruction set based on the outcome of that test.

And to implement this in C or C++ or any language of choice would require you to master parsing (the reading of) characters and acting on that, what you are basically doing, or trying to do already.

I think if you were able to wrap your mind around that, then nothing would stand in your way, or at least, not much else.

Maybe putting yourself in the shoes of a computer will get rid of some of these snags you're having with this particular problem.
This really will be the last time I do this, though. For reals, I'm not going to make it a hat trick, honest. I just think you'll benefit more from a more general approach to computing than focusing on a programming language, even though I AM suggesting to write a CPU/virtual machine using one.
Its just to give you something to think about. You're so close but whenever I read these posts of yours you seem to get lost because of the somewhat arbitrary nature of C and its things.

Hence me suggesting thinking in the very basics for your own machine, opcodes/instructions and all that good stuff.
What, or how would YOU do a CPU, a computing machine that can do anything?

How would you design it? What do you think must happen for an unliving electrified hunk of silicon to do anything it is being told?
How would you weave such magics? How would you make rocks think for you?

2 members found this post helpful.

Geist, I've put writing anymore programs, or trying to fix the program that was being discussed in this thread on hold for now. And I'm currently watching the videos GazL linked earlier on in this thread, as well as focusing on what astrogeek was talking about in post #94 - learning to think algorithmically rather than just focusing on the code.

So reading a wall of text isn't anymore helpful than trying to read a wall of code. So like I said, I'm deferring everything except the concepts and thinking algorithmically until a later date - until I've got the concepts and thinking algorithmically under control.

That said, the explanation of the code GazL gave in post #99 is finally starting to make sense now. I won't get too cocky yet, and I'm up to the video about loops now too. So I must thank you again for that link GazL, thanks again!!

Well, I've reached the end of the videos I mentioned above that I was watching on YouTube, that GazL linked to earlier on. They did fill in quite a few blanks, and nearly all of it made sense - other than a few of the mathematical related things. Like how Caleb calculated the "factorial" of 5 from memory, it wasn't the code itself he used per se - I just don't get how it worked (it was in one of the videos about functions or one of them just before he started on functions, but I can't remember exactly which one it was). I did get what it was saying, and at least sorta understand what he was saying about "factorials"/what they are, but yeah, don't really get how or why he done what he done to calculate it.

But nevertheless, and like I said, they did fill in quite a few blanks and answered some of the things I still wasn't quite sure about. His explanation of pointers and a few other things really made sense, so I think I can finally say "I get it" as far as at least what pointers actually are and how to use them. In particular, I had a epiphany in that, the Programming in C book by Stephen Kochan I was reading calls the address-of operator just the "address operator" from memory, and not the "address-of operator". But Caleb kept calling it the "address-of operator", and it occurred to me that, it's easier to understand the meaning of it with the "of" on the end of the word "address", and therefore it's much easier to read and understand what the code is actually saying when instead of thinking just the "address operator", thinking the "address-of operator". So for example, beforehand trying to read and understand what say "int *ptr = &myvar" (bad variable names I know, but just a quick example ) is saying and meaning; I might have read it as "integer pointer assigned to address myvar". But it didn't make much sense reading like that, so thinking when seeing the ampersand with "address-of" (in that context - I know it can also mean the bitwise AND operator and the logical AND operator), and therefore reading the same as "declaring an integer pointer called ptr and assigning it's value to the address-of myvar" instead, makes it so much easier to read and understand. I don't know why I didn't realize this sooner

In any case, those videos were quite helpful, but I'll still have to work on thinking more algorithmically, and the mathematics while at least a little easier now, it's still not really what I'd call "really good", just a little better. But still, trying to understand some of the mathematical concepts both Caleb was talking about, and that I've seen elsewhere, and things like division are still at least a little beyond me.

In any case I'll mark this thread as [SOLVED] since I think my questions have been answered - so hopefully I've understood the answers

Thanks again everyone!

4 members found this post helpful.