tags:

views:

344

answers:

10

First of all, sorry, but my English is not very good.

I'm at the third semester at a programming course and I can't "get it".

I passed previous exams because I've studied three times the amount my colleagues did. And, now in my Data Structures class when the professor asks us to make list algorithms ( for example ), my colleagues just start to write the code while me ( or would be "I"? ), even after seeing it done, can't understand.

I find it so hard it's painful. It takes me 1 hour to understand simple algorithms.

So the question is: can anyone recommend me books or something, that will help me think more like a programmer? I mean, "normal" people, after a given problem, seem to immediately make the picture in their head and star to write the code.

+8  A: 

you might want to take a philosophy class on intro to logic. it's exactly the same thing as you're doing with computers, but in a different context.

atk
+1 for the philosophy logic class... that's really thinking outside the box.
Peter Tillemans
+5  A: 

If it helps, you might want to try books in your native language. If there is any gap in your understanding that comes from your English comprehension, that would add additional difficulty for you.

Second, an algorithm, is just a list of steps for achieving something. Try to focus on something simple like sorting algorithms, they are fun and easy to learn. Hope that helps.

funkymushroom
I agree with both ideas, especially the second. Certainly you (the original poster) solve problems analytically and logically every day. The only trick to programming (other than learning the syntax) is being able to be aware of each of the steps that fit into your natural problem-solving process.Before writing any actual code, I spend a long time thinking through each step that leads to the end result. Then I wrap these steps in any necessary conditions, and slowly my pseudocode turns into real, functioning code. As an added bonus, it usually ends up with lots of comments, too!
mlms13
+2  A: 

If you want to jump in the deep end and are willing to work hard, there is "Structure and Interpretation of Computer Programs". It is out of print but available on the net.

It goes deep into conceptual thinking processes behind programming and converting them to code. It uses scheme, but the principles are applicable everywhere and it is great training for flexing the abstraction muscles.

Don't do it in one go... take your time with it, come back regularly to it, and have fun!

Peter Tillemans
+2  A: 

I think there are two ways to learn to write algorithms: 1. Try it yourself (and then review it with the "right" answer). Of course you should start with the simple ones. 2. Implement other's algorithms (to code). Going from algorithms to code and the other way around gives you a great "feeling" of how algorithms are created.

But the best advice I can give you (which you can use the two ways above to acquire) - try being very good at some algorithms. If you could remember, write and really understand even just a few basic algorithms - you're on the right way.

Anyways, I think learning algorithms is mainly practice and less "abstract knowledge", so get ready to get your hands dirty..

Best of luck!!

Oren A
+5  A: 

I found that the most important skill for mastering data structures is to "visualize" them. If you have no clear picture of your data structure, everything stays fuzzy and vague. E.g. take a stack (single linked list). It may help to visualize it as a stack of plates or people in a polonaise (everyone has the hands on the shoulders of the person in front of him).

Or a double linked list: Imagine a row of people grabbing the belt of the left and right neighbor. Now you can imagine what you must do to remove one person: Its left neighbor needs to grab the belt of the right neighbor and the right neighbor the one of the left neighbor. Then you can "delete" that person (or the garbage collector does this for you in Java etc)

The second important skill is to understand recursion. You need always a base case, usually involving an empty list or empty node. When you follow the algorithm in the recursive method, check that it is correct, but don't follow recursive calls inside that method. That will drive you mad and lead to nothing. Just assume that recursive calls always "do the right thing". If your current method is correct and the base case as well, you are done. Once you understood this, you understand recursion.

Landei
+1 for a good analogy.
casablanca
For recursion, I disagree about not following the case - that is what you do when you already grok recursion. But when learning, it's important to follow a trivial 5-node exmaple all the way thru.
FastAl
Another thing... WAY more important when learing recursion is that __you must understand all passed parameters and local variables go on the call stack__!!! So a prerequisite to writing recursive functions is ABSOLUTETLY knowing (1) the stack data structure (2) EXACTLY how parameters are passed (e.g., the names being passed in don't matter,etc); (3) how parms and local variables are put on the stack. Otherwise the logical answer: recursion is impossible!
FastAl
+3  A: 

I think it is a good practice to use diagrams before implementing anything. You can make diagrams or write a pseudo code, they are helpful before you start to design or implement the actual code.

PC2st
+2  A: 

Try to think about how you approach everyday cognitive problems, and formalize the steps you take to solve them, on paper.

For example, if you've ever had to reorder a deck of 52 jumbled cards, you probably know Insertion sort or some variant of Merge Sort already. If you're asked to sort five 2-digit numbers in your head, you're probably using Selection Sort. If you've had to find a specific card from a jumbled deck, you probably used Linear Search. If you've ever seen the 'High Low Game' on 'The Price is Right', you probably know Binary Search. If you're asked to solve the 8-Queens problem as a 'puzzle', you will almost certainly use the classic backtracking technique.

Don't let jargon like 'loop invariant' or 'asymptotic time complexity' intimidate you straight away. Think about how an algorithm is dealing with the problem, and you will find yourself 'rediscovering' these terms yourself when you want to reason about its correctness or efficiency.

Ani
+3  A: 

I do not know how far this problem is concerned, but it might help.

Algorithms and data structures are way cleaner for me if I think of them just as informal ideas/boxes/shapes/forms/connections/... instead of abstract things.

That is, everytime I come across a new data structure I try to visualize it somehow in order to actually beeing able to "see" what the single operations do with the structure.

I had also sometimes the problem that I didn't actually know instantly how to solve something algorithmically, so I just went ahead and started drawing.

Let's take - as an example - the problem of converting a binary tree into a list. So, I draw a tree (of arbitrary size and holding arbitrary elements, but beeing a "good" example). Then I think how I would convert the tree into a list manually:

        1
    2       3
  4   5   6   7

So I think: I want to have the result [4,2,5,1,6,3,7]. How can I do this step-by-step?

Ok, first of all, I find the leftmost element (4); how can I do this? Ok, I start just by the root and go left until there's nothing more. Then I remove this element and go on with the remaining tree:

        1
    2       3
  .   5   6   7

Ok, now I would pick the 2. How can I reach the 2? Ok, I can either start again at the root and go left until there's nothing more or i just go back from the deleted node.

Then I go on and look for recurring patterns, how one can generalize steps etc.

The outcome is, it might often be helpful to have a visual representation of what the algorithm is doing and then you can implement it.

phimuemue
+2  A: 

I had a similar problem when I was first introduced to programming languages. I missed a lot of lectures because it was my first year of college! For me there was no books or lecturers that I found that knew how to help you think like a programmer. I always found the people teaching didn't know how 'not' to think like a programmer anymore and as a result they assume you know the simple concepts. So finally by the end of my first year I had to cram majorly to catch up and and had to fill in the gaps myself...! This is how I think about programming problems now:

OBJECTS: For Object-Oriented programming objects are the key to the whole thing. If you think about what it is your program needs to be able to do then you can break up the program into smaller chunks. For example, if you imagine making a cup of tea, the objects you need to make the cup of tea are:

1 -> A cup
2 -> A tea bag
3 -> Water
4 -> A kettle
5 -> A spoon
6 -> Milk
7 -> Sugar

So now your program has 7 objects which will interact in some way to make a cup of tea. Objects are always declared as their own class and will have constructor methods which when called will create a copy (instantiation) of your object that can then be used in your program. All of the method that are inside your class will define what functionality your object can provide.

Kettle kettle = new Kettle();
kettle.boilWater();

So now that you have your objects you should think about your algorithm.

ALGORITHMS: In all programming languages an algorithm is basically just a list of steps that you take that will help you achieve your end goal. In our case our end goal is to make a cup of tea.

The steps you will take in your algorithm have to come one after the other in a logical fashion i.e. You cannot pour the milk into the kettle, or pour cold water into the cup and boil the sugar etc.

So our algorithm can be as follows:

Step 1: Pour water into Kettle
Step 2: Turn kettle on - to boil the water
Step 3: Put tea-bag into cup
Step 4: "IF" water is boiled -> pour into cup
        "ELSE" wait until water has boiled
Step 5: Stir teabag with spoon
Step 6: Pour milk into cup
Step 7: Put sugar into cup
Step 8: Stir

There are always a few different ways you can arrange the steps in an algorithms that will still work but always remember to have a logical order or else you will make a mess!!

The same principle can be applied to even the most complex problems. The most important thing to do is try to break the problem down into the simplest steps and arrange the steps in a common sense way.

When it comes to more complex tasks it is obviously very important to know what tools you have available to you i.e. know what functionality APIs provide you with and be familiar with the syntax. But as people have mentioned to you already before practice makes perfect. It is the only way that you will begin to understand it and believe me you will get it eventually... One day it WILL all make sense to you it is just about thinking a certain way. Break everything down to small simple steps and then order the steps in a logical way. Do this and it will start to make sense to you. I PROMISE!!

travega
+1  A: 

I'd suggest you could try out some of the websites which contain a number of algorithmic problems to solve. Usually you could find a number of very easy problems to start with, and forums to discuss them. Then it's up to you and how much time you spend on them. Just try to go into as much detail as possible and question yourself what exactly is it that you don't understand, then how could you figure that out (maybe someone already had figured that out and you just need to find the answer). For the easiest problems Google is more than enough to find the answers you're looking for.

And here is the list of websites you could try:
uva.onlinejudge.org - Huge list of problems related to different algorithms.
www.topcoder.com/tc - Live competitions and lots of tutorials to get started.
www.algorithmist.com - Constains a list of links collected over time by problem-solvers.

Leonid