I am a 2nd year computer science student. We all have subjects about Data Structures, Theories, more more theories we all know that i have a subject this semester Design Analysis of Algorithms.

So my question is. How do you guys understand well all the Algorithms? Any technique?

To snap out the confusion about my question, I just want to know your techniques in learning algorithms. We all know that Algorithms is very important aside from the Programming stuffs and some students find it hard to understand and considered me sometimes ..... I don't have problems in Programming subjects (not boasting) but I excel in Programming and I'm very interested to dive deep in learning more about Algorithms. Some people don't think that Data Structures and Design Analysis of Algorithms an important subjects. But i do really think that learning more about Algorithms is a very efficient way in learning in programming too. So any answers will be highly appreciated!

  • $\begingroup$ Every program you write is an algorithm. If you excel at programming, you already excel at algorithms. (Or, put another way, if you're using bad algorithms, you're not excelling at programming.) $\endgroup$ – David Richerby Jul 4 '14 at 8:48
  • $\begingroup$ Thank you for the answer sir! But how do you understand well algorithms? And for you sir, what really is the purpose of this kind of subjects. $\endgroup$ – Christian. Jul 4 '14 at 9:02
  • 2
    $\begingroup$ Welcome to Stack Exchange. This is a questions and answers site, not a discussion forum. What you've posted here is a discussion starter, not an answerable question. (And even as a discussion starter I don't understand what you're after.) $\endgroup$ – Gilles 'SO- stop being evil' Jul 4 '14 at 10:10
  • 1
    $\begingroup$ I edited your question. The title was not precise enough, and you should watch more your syntax and style. There is still a missing word (see dots) that I was unable to guess. However, it is up to you to modify it so that it might be acceptable to the moderators by fitting better the rules for questions. $\endgroup$ – babou Jul 4 '14 at 11:50
  • $\begingroup$ @Christian Practice, Practice, and more Practice! Buy books on algorithms and read them. Buy books on math and read those too. Do all the exercises! That's what I do at least. $\endgroup$ – Gary D. Jul 4 '14 at 13:17

There is a 35 years old result in Logic (the Curry-Howard correspondance) that states (simplifying a bit) that algorithms are like (isomophic to) proofs. If you take the specification of a program/algorithm such as, Given a sequence of integer, give a sorted sequence of the same integers in ascending order. This may be read as the statement of a theorem For any sequence of integer, there is a sequence that contains the same integers in ascending order. And any algorithm meeting the specification will actually correspond to a proof of the theorem.

Most professionnals will never be asked to use this correspondence (at least in the current state of the technology), but it does provide some understanding of the programming process.

What this indicates is that to understand algorithms, you have to inscribe them in a structured body of systematic knowledge, as much as possible, as you would do for mathematics. And mathematics does also play a role. What matters is understanding the structural underpinnings of the type of entities you are dealing with, so that you have an organized vision of what can or cannot be done, when and how. Note that some algorithms use other algorithms as components, exactly as some theorems are used to prove others.

Or to put it another way, you can work programming and algorithmic design exactly the same way you work on a mathematical problem. In mathematics, you learn a collection of definitions and of theorems that involve these definitions. Given a problem, you try to identify structures or entities that meet the definitions you know, for both hypothesis and conclusion, and you try to apply the theorems to get a proof.

When given a programming problem, you do exactly the same: you try to identify data structures or abstract types and programming structures that would adequately represent the entities you are supposed to deal with, and then you try to compose various algorithms (theorems) to actually get the work done.

In mathematics, what matters in some cases is the proof technique rather than, or as much as, the result. You sometimes have to reuse the same proof technique in a different context. The same goes for algorithms. If you understand how they are designed, you can use a similar design for other algorithms, in situations where known one do not exactly apply. So it is not just knowing algorithms that matters, but much more understanding them, understanding what makes them tick the right way. And that is not always easy. Some research improvements in algorithms result precisely from trying to understand the deep reasons that make some of them work the way they do. And this often involve understanding mathematical structures.

More generally, understanding a mathematical theory is not rote learning of a collection of definitions and theorems (though it sometimes help for specific very technical aspects). It is getting an overall, structural mental picture of the various aspects of the theory and the ways they interact. The same goes for algorithms. For example you may want to study and understand in a global way how one can deal with graphs. The various algorithms may have relations. Then, given a problem, you may recognize that part of it may be seen as a graph problem, and deal with it accordingly.

This said, the world may be a somewhat simpler place for most programmers. But the more you understand, the better you do.

I would like to point out that this is not the only facet of programming. Of course, a good program must use good algorithmics. But it often is not enough. Style and architecture matter. Your program must be easy to understand and maintain. From a mathematics point of view, this may correspond to what is called an elegant proof. The choice of the programming language may matter, as the choice of the right notations may matter in mathematics. But that is a bit beyond your question.

I am sure there is a lot more to say.

| cite | improve this answer | |
  • $\begingroup$ This is the best answer! Thanks for clarifying this sir @babou! I just believe that understanding well or mastering algorithms is one way in proving that you are a real programmer. What i mean is anyone can code its easy to learn to program and to solve a machine problem is you need your self understanding at problems and that depends on your logic how you think. But not all do know the real algorithm. The theories(huffmans, greedy, etc) I believe that having a solid base of algorithmic knowledge and techniques is one characteristics that separates truly skilled programmers than the novice. $\endgroup$ – Christian. Jul 5 '14 at 2:30
  • $\begingroup$ @Christian. As I said, "mastering algorithms" is not exactly one way of being a good programmer, it is one part of the way. One other part is understanding programming structures, concepts and organization, such as type systems, environments, scoping, modularity, programming paradigms, etc. so as to choose adequately your programming languages and to properly design the architecture of your systems. It is not all as easy and intuitive as it might seem. Algorithms are the words of your language, and programming concepts are the way you organize them into meaningful sentences. Good luck. $\endgroup$ – babou Jul 5 '14 at 9:25
  • $\begingroup$ Yes sir! I'm already have subjects programming languages too which we learn about different programming paradigms(imperative, object oriented, functional and Logical) paradigms. It really gets my interest! Although i've known Object Oriented in Java Functional and Logic gets my interest :) but anyways thank you for the answer sir! I really appreciate it and take note all what you've said! God bless! $\endgroup$ – Christian. Jul 5 '14 at 16:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.