understand c programming logic but can't write a tough program

Thread Starter

khatus

Joined Jul 2, 2018
95
Hello guys I am a beginner in c programming.I understand the logic behind a solved problem in c programming, but I can't write a tough program(like Pascal's triangle,pyramid) without any algorithm or flowchart by myself.When the program gets a little tough, I can't solve it. What should I do now?Which book should i follow.I need some useful advice.
 

WBahn

Joined Mar 31, 2012
29,976
You need to write lots of programs where you have to come up with the algorithm yourself.

Work with smaller/simpler programs that you can handle and then make them slightly more complicated.

You can also work with larger programs where you have someone else's algorithm and then modify them slightly to achieve slight different things.

Also, recreating algorithms on your own even if they are straight up implementations of someone else's algorithm is helpful. In other words, study someone else's algorithm to solve a problem, but then set it aside and do the problem yourself. This forces you to go through the process of creating the algorithm even though you have a path in mind.
 

dl324

Joined Mar 30, 2015
16,845
When the program gets a little tough, I can't solve it. What should I do now?Which book should i follow.I need some useful advice.
In this day and age, you just search the internet for solutions for problems that have already been solved.

This is the first hit in my search:
https://www.codewithc.com/pascals-triangle-algorithm-flowchart/

There are many books covering algorithms for solving problems. I'm partial to articles/books written by Donald Knuth.
 

WBahn

Joined Mar 31, 2012
29,976
In this day and age, you just search the internet for solutions for problems that have already been solved.

This is the first hit in my search:
https://www.codewithc.com/pascals-triangle-algorithm-flowchart/

There are many books covering algorithms for solving problems. I'm partial to articles/books written by Donald Knuth.
But the TS isn't looking for someone else's solution to Pascal's Triangle -- he is asking how to develop the ability to solve, for himself, (what for him at this stage are) tough problems WITHOUT resorting to using someone else's algorithm.
 

JohnInTX

Joined Jun 26, 2012
4,787
I think it's OK to look at someone's solution to a problem, that's what textbooks are for after all. But the important thing is to study that solution until you not only understand exactly how it works but also learn the underlying principles so that you can apply those principles to new problems that may not have a solution yet. One of the best pieces of advice I got as a pup was to read code, lots of it and study what the programmer did to solve his particular problem.

It's far too common to find some piece of code on the internet, copy it and declare victory. It is also common to run into problems when that code doesn't exactly fit the problem and the user doesn't understand enough to adapt the code or derive a suitable alternative. The perils of 'copy without comprehension' are many and unfortunately are far too often on display right here on AAC.
 

WBahn

Joined Mar 31, 2012
29,976
Practice and experience. For fun (and you might learn something), watch how this guy solves problems:

I only watched the first couple minutes of the interview, but noted a very key thing that I always looked for when I was conducting technical interviews. I really didn't care whether the person was able to solve the problem easily (or even at all), what I wanted to see what their problem solving approach. I didn't even care if it was laser focused or took a meandering path. I primarily wanted to see them breaking the problem down, thinking about subtle points, asking or verifying that what they were doing was reasonable along the way, and applying what they already knew to something that (hopefully) was different than what they might have seen up to this point. Talking to yourself or asking clarifying questions, even if they are purely rhetorical, and explaining what you are doing and why goes a long way in conveying to the interviewer that you have a problem-solving mindset instead of a regurgitation-only mindset.
 

WBahn

Joined Mar 31, 2012
29,976
I think it's OK to look at someone's solution to a problem, that's what textbooks are for after all. But the important thing is to study that solution until you not only understand exactly how it works but also learn the underlying principles so that you can apply those principles to new problems that may not have a solution yet.

It's far too common to find some piece of code on the internet, copy it and declare victory. It is also common to run into problems when that code doesn't exactly fit the problem and the user doesn't understand enough to adapt the code or derive a suitable alternative. The perils of 'copy without comprehension' are many and unfortunately are far too often on display right here on AAC.
I agree.

It's perfectly okay to look at other solutions and learn from them -- that IS a key element of the process. That helps you build a toolbox of approaches that you can draw upon later. But having a good set of tools is far from being good at using those tools. Too many people equate finding a solution to a problem with crafting a solution to a problem.
 

djsfantasi

Joined Apr 11, 2010
9,156
I was trying to write a follow up to WBahn’s first post and he wrote it himself.

Coding many algorithms yourself leads to developing the toolbox that WBahn mentions. And then he proceeds to point out that in addition to putting an algorithm in your toolbox, you need to know how to use it in various scenarios.

I agree.

I’ve been coding for about fifty years. And because of the years of practice, after reading a problem statement, I can write a program in a very short time. Something simple, like your examples, might take ten minutes or less. But, I’ve been coding similar programs for fifty years
 

MrSoftware

Joined Oct 29, 2013
2,188
I only watched the first couple minutes of the interview, but noted a very key thing that I always looked for when I was conducting technical interviews. I really didn't care whether the person was able to solve the problem easily (or even at all), what I wanted to see what their problem solving approach. I didn't even care if it was laser focused or took a meandering path. I primarily wanted to see them breaking the problem down, thinking about subtle points, asking or verifying that what they were doing was reasonable along the way, and applying what they already knew to something that (hopefully) was different than what they might have seen up to this point. Talking to yourself or asking clarifying questions, even if they are purely rhetorical, and explaining what you are doing and why goes a long way in conveying to the interviewer that you have a problem-solving mindset instead of a regurgitation-only mindset.
Yes that's what I was hoping the TS would notice, the way the guy breaks things down into manageable pieces and works through them.
 
Top