LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 11-15-2019, 01:09 AM   #121
astrogeek
Moderator
 
Registered: Oct 2008
Distribution: Slackware [64]-X.{0|1|2|37|-current} ::12<=X<=14, FreeBSD_12{.0|.1}
Posts: 5,249
Blog Entries: 11

Rep: Reputation: 3222Reputation: 3222Reputation: 3222Reputation: 3222Reputation: 3222Reputation: 3222Reputation: 3222Reputation: 3222Reputation: 3222Reputation: 3222Reputation: 3222

Quote:
Originally Posted by jsbjsb001 View Post
It's trying to follow it and predict what the program is likely to do next, and the next move the computer going to make - basically "thinking like a computer".
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):

Code:
* Start
* Walk to street out front, turn right and go to corner
* At corner, turn right go to next corner
* At next corner, turn right go to next corner
* At next corner, turn right go to next corner
* At next corner, turn right go to your home
* Done
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:

Code:
If your issue(s) have been solved, please mark your thread as [SOLVED] at the top of the thread.


           Start
             |
             |
             |
             v
             X         +--------+
  Issue     / \  Y     |  Mark  |
 Solved?   X   x------>| SOLVED |---+
            \ /        |        |   |
             X         +--------+   |
             | N                    |
             |                      |
             |<---------------------+
             |
             v
           Done

If it's important to you, did you backup it up? If you didn't, then it can't be important to you!

           Start
             |
             |
             |       Backed up?
             v
             X           X        +--------+
Important   / \ Y       / \ N     |  Make  |
 to you?   X   x------>X   x----->| Backup |---+
            \ /         \ /       |        |   |
             X           x        +--------+   |
             | N         | Y                   |
             |           v                     |
             |<--------------------------------+
             |
             v
           Done
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!

Last edited by astrogeek; 11-15-2019 at 01:17 AM. Reason: tpoy
 
1 members found this post helpful.
Old 11-15-2019, 10:15 AM   #122
rtmistler
Moderator
 
Registered: Mar 2011
Location: MA, USA
Distribution: MINT Debian, Angstrom, SUSE, Ubuntu, Debian
Posts: 8,155
Blog Entries: 13

Rep: Reputation: 3566Reputation: 3566Reputation: 3566Reputation: 3566Reputation: 3566Reputation: 3566Reputation: 3566Reputation: 3566Reputation: 3566Reputation: 3566Reputation: 3566
I agree with the continued points by Astrogeek, GazL, and others.
Quote:
Originally Posted by jsbjsb001 View Post
It's trying to follow it and predict what the program is likely to do next, and the next move the computer going to make
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.
 
2 members found this post helpful.
Old 11-15-2019, 10:25 AM   #123
NevemTeve
Senior Member
 
Registered: Oct 2011
Location: Budapest
Distribution: Debian/GNU/Linux, AIX
Posts: 3,882

Rep: Reputation: 1356Reputation: 1356Reputation: 1356Reputation: 1356Reputation: 1356Reputation: 1356Reputation: 1356Reputation: 1356Reputation: 1356Reputation: 1356
A little interrupt in debugging might do good: https://www.google.com/doodles/celeb...of-kids-coding
 
Old 11-16-2019, 07:36 AM   #124
jsbjsb001
Senior Member
 
Registered: Mar 2009
Location: Earth? I would say I hope so but I'm not so sure about that... I could just be a figment of your imagination too.
Distribution: Currently OpenMandriva. Previously openSUSE, PCLinuxOS, CentOS, among others over the years.
Posts: 3,230

Original Poster
Rep: Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663
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.
 
Old 11-16-2019, 12:11 PM   #125
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,257
Blog Entries: 18

Rep: Reputation: 3013Reputation: 3013Reputation: 3013Reputation: 3013Reputation: 3013Reputation: 3013Reputation: 3013Reputation: 3013Reputation: 3013Reputation: 3013Reputation: 3013
Quote:
Originally Posted by jsbjsb001 View Post
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".
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).

Last edited by GazL; 11-16-2019 at 12:18 PM.
 
Old 11-17-2019, 05:04 AM   #126
jsbjsb001
Senior Member
 
Registered: Mar 2009
Location: Earth? I would say I hope so but I'm not so sure about that... I could just be a figment of your imagination too.
Distribution: Currently OpenMandriva. Previously openSUSE, PCLinuxOS, CentOS, among others over the years.
Posts: 3,230

Original Poster
Rep: Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663Reputation: 1663
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).
 
  


Reply

Tags
fgets, strings


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Tabs or spaces? Spaces, obviously, but how many? LXer Syndicated Linux News 0 09-13-2018 10:50 AM
block special and character special files s_shenbaga Linux - Newbie 4 06-23-2015 03:16 AM
LXer: Special mention for Special purpose LXer Syndicated Linux News 0 04-22-2011 12:11 PM
renaming files with spaces and special characters. bowens44 Linux - Newbie 8 06-29-2009 07:52 PM
Spaces and escaped spaces pslacerda Linux - Newbie 13 12-20-2008 10:03 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 01:33 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration