This question already has answers here:
What is recursion and when should I use it?
(40 answers)
Closed 9 years ago.
I am wondering, why do people use recursion? In most of my learning experience, I've found it to be much more inefficient that iterative methods, so why do people use it? Is it because you can simply write a shorter method? Is it used in real-world programming outside the classroom setting (or learning purposes)? If it is, please provide a good example if you can, I'm very curious.
Thanks in advance for your help! I really appreciate it!
If you have a tree data structure and you want to walk over it in depth-first order, recursion is the only way to do it.
If you want to write a parser for a typical language having context-free rules, like every programming language in existence, a recursive-descent parser is a simple and natural way to do it.
There is no iterative way to do it with limited storage.
Well, for one thing, it's used in functional programming languages (like Haskell), which don't really have iteration, and they are optimized for recursion. Also, for some problems (like working with binary trees), recursions is a very natural and clean solution.
Related
Some problems that require recursion have always put me in a fix. I am not always able to come up with a recursive algorithm, but I know that there is a recursive solution to the problem.
I find problems like factorial and fibonacci easy to implement using recursive approach. But when I face more complex problems such as generating the partition of a number http://en.wikipedia.org/wiki/Partition_%28number_theory%29, I know that there is a possible recursive approach but I get stuck right there. I can't devise a recursive algorithm. Suppose I want to print all combinations of a string or if I want to bruteforce a Coin Change problem using recursion, I can't devise a recursive approach.
Is there any particular way to think so as to come up with a recursive approach? Is there any extensive recursive algorithms tutorial out there which can help me solve more advanced problems?
Look through the Structure and Interpretation of Computer Programs book, which is highly recommended here on Stack Overflow and is freely available online. It uses the Scheme programming language to teach fundamental concepts about programming. Since Scheme is a functional programming language, recursion is widely used everywhere - not only where you would use it even in imperative programming languages such as C or PHP, but also where you would typically use a looping construct. The examples and problems in the book present recursion in its natural habitat, if you will, and not through convoluted made-up scenarios.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Do you memorize algorithms such as binary search / quick sort / whatever. If so, do you have any tricks for doing so?
Its always better to find ways to understand the underlying principle of such algorithms rather than memorizing them. For example - Quick Sort uses Divide and Conquer paradigm (it is a design technique to solve a certain class of problems).
Wiki is a very good starting point to dissect a new topic. You can dig deep by watching video lectures (found this good post on Video Lectures here on SO) and other specific material such as concerned research papers.
Working out examples will also clarify the algorithm better.
I hope this helps.
cheers
I don't memorize them in the sense of rote memorization of code or pseucode, but I could always code binary search and quicksort from memory because I know how the logic works. This comes from studying algorithms, which I absolutely recommend.
I think that it is worthwhile remembering the concepts behind important algorithms and data structures. But for the implementation side, I would argue to use a library function if at all possible. It is easy to forget about borderline cases when you write down the algorithm - and it is quite probable that you don't think of them if you do a unit test. As a result, even such simple algorithms as binary search are likely to be broken:
I remember vividly Jon Bentley's first Algorithms lecture at CMU, where he asked all of us incoming Ph.D. students to write a binary search, and then dissected one of our implementations in front of the class. Of course it was broken, as were most of our implementations.
From the Google Research blog. The rest of the text is a recommendation worth as well, but it's not about memorizing algorithms.
Seek to comprehend instead of memorizing. I find it helps me to work through proofs of an algorithm to get the inner workings of what's going on, and that's usually proven to be good mnemonic strategy.
You should know the general principles behind these algorithms because they are the fundamentals of programming and it will give you insight into where they should be used. For example, you should understand quick sort well enough to understand why it can be O(N^2) in pathological cases.
However, there is absolutely no point in remembering enough detail to be able to code production quality implementations of these algorithms on the first try off the top of your head. This is what libraries are for. For example, if all you remember is the canonical 3-line version of the quick sort and you can't remember how to implement one that doesn't easily find the O(N^2) cases and sorts in place, there's nothing wrong with that.
I would never risk trying to memorize these - always try to find a library function which handles it.
No, that is what the Internet is for. I'd rather demand page that kind of knowledge in, rather than have it take up space for something more useful.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Every language that is being used is being used for its advantages, generally.
What are the advantages of Prolog?
What are the general situations/ category of problems where one can use Prolog more efficiently than any other language?
Compared to what exactly? Prolog is really just the pre-eminent implementation of logic programming so if your question is really about a comparison of programming paradigms well that's really very broad indeed and you should look here.
If your question is more specifically about prolog vs the more commonly seen OO languages I would argue that you're really comparing apples to oranges - the "advantage" (such as it is) is just a different way of thinking about the world, and sometimes changing the way you ask a question provides a better tool for solving a problem.
Basically, if your program can be stated easily as declaritive formal logic statements, Prolog (or another language in that family) will give the fastest development time. If you use a good Prolog compiler, it will also give the best performance and reliability, because the engine will have had a lot of design and development effort.
Trying to implement this kind of thing in another language tends to be a mess. The cleanest and most general solution probably involves implementing your own unification engine. Even naive implementations aren't exactly trivial, the Warren Abstract Machine has a book or two written about it, and doing better will at the very least involve a fair bit of research, reading some headache-inducing papers.
Of course in the real world, key parts of your program may benefit from Prolog, but a lot of other stuff is better handled using another language. That's why a lot of Prolog compilers can interface with, e.g., C.
One of the best times to use Prolog is when you have a problem suited to solving with backtracking. And that is when you have lots of possible solutions to a problem, and perhaps you want to order them to include/exclude depending on some context. This suggests a lot of ambiguity... as in natural language processing.
It sure would be a lot tidier to write all the potential answers as Prolog clauses. With a imperative language all I think you can really do is write a giant (really giant) CASE statement, which is not too fun.
The stuff that are inherent in Prolog:
pattern matching!
anything that involves a depth first search. ( in Java if you want to do a DFS, you may want to implement it by a visitor pattern or do a (really giant) CASE
unification
??
Paul Graham, is a Lisp person nonetheless he argues that Prolog is really good for 2% of the problems, I am myself like to break this 2% down and figure how he'd come up with such number.
His argument for "better" languages is "less code, more power". Prolog is definitely "less code" and if you go for latter flavours of it (typed ones), you get more power too. The only thing that bothered me when using Prolog is the fact that I don't have random access in lists (no arrays).
Prolog is a very high level programming language. An analogy could be (Prolog : C) as (C : Assembler)
Why is not used that much then? I think that it has to do with the machines we use; They are based on turing machines. C can be compiled into byte code automatically, but Prolog is compiled to run on an emulation of the Abstract Warren Machine, thus, it is not that efficient.
Also, prolog is based on first order logic which is not capable of solving every solvable problem in a declarative manner, thus, at some point, you need to rely on imperative-like code.
I'd say prolog works well for problems where a knowledge base forms an important part of the solution. Especially when the knowledge structure is suited to be encoded as logical rules.
For example, writing a natural language interpreter for a particular problem domain would require a lot of knowledge in that domain. Expert systems also fall within this knowledge driven category.
It's also a nice language to explore solutions to logical puzzles ;-)
I have been programming (for fun) over a year with Swi-Prolog. I think one of the advantages of Prolog is that Prolog has no side effects: Prolog is language that kind of has no use for (local or class member) variables, it kind of forces the programmer not use variables. Prolog objects have no state, kind of. I think. I have been writing command line Prolog (no GUI, except few XPCE tests): it is like a train on a track.
I'm trying to apply the simplified algorithm in Prolog, but I'm not a Prolog master. I need it without any mistakes, so I thought you guys might be able to help.
What is the implementation of DPLL algorithm in Prolog?
Putting "dpll algorithm prolog code" into Google returns this very nice source file as the first result. It's probably way too neat and nice to be handed in as homework without extensive cutting-down and messing-up.
http://www.mscs.mu.edu/~cstruble/class/cosc159/spring2004/code/dpll.pl
The second result is this question page here, as SO is highly ranked.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What are some simple algorithm or data structure related "white boarding" problems that you find effective during the candidate screening process?
I have some simple ones that I use to validate problem solving skills and that can be simply expressed but have some opportunity for the application of some heuristics.
One of the basics that I use for junior developers is:
Write a C# method that takes a string which contains a set of words (a sentence) and rotates those words X number of places to the right. When a word in the last position of the sentence is rotated it should show up at the front of the resulting string.
When a candidate answers this question I look to see that they available .NET data structures and methods (string.Join, string.Split, List, etc...) to solve the problem. I also look for them to identify special cases for optimization. Like the number of times that the words need to be rotated isn't really X it's X % number of words.
What are some of the white board problems that you use to interview a candidate and what are some of the things you look for in an answer (do not need to post the actual answer).
I enjoy the classic "what's the difference between a LinkedList and an ArrayList (or between a linked list and an array/vector) and why would you choose one or the other?"
The kind of answer I hope for is one that includes discussion of:
insertion performance
iteration performance
memory allocation/reallocation impact
impact of removing elements from the beginning/middle/end
how knowing (or not knowing) the maximum size of the list can affect the decision
Once when I was interviewing for Microsoft in college, the guy asked me how to detect a cycle in a linked list.
Having discussed in class the prior week the optimal solution to the problem, I started to tell him.
He told me, "No, no, everybody gives me that solution. Give me a different one."
I argued that my solution was optimal. He said, "I know it's optimal. Give me a sub-optimal one."
At the same time, it's a pretty good problem.
When interviewing recently, I was often asked to implement a data structure, usually LinkedList or HashMap. Both of these are easy enough to be doable in a short time, and difficult enough to eliminate the clueless.
This doesn't necessarily touch on OOP capabilities but in our last set of interviews we used a selection of buggy code from the Bug of the Month list. Watching the candidates find the bugs shows their analytical capabilities, shows the know how to interpret somebody elses code
Write a method that takes a string, and returns true if that string is a number.(anything with regex as the most effective answer for an interview)
Please write an abstract factory method, that doesn't contain a switch and returns types with the base type of "X". (Looking for patterns, looking for reflection, looking for them to not side step and use an if else if)
Please split the string "every;thing|;|else|;|in|;|he;re" by the token "|;|".(multi character tokens are not allowed at least in .net, so looking for creativity, the best solution is a total hack)
Graphs are tough, because most non-trivial graph problems tend to require a decent amount of actual code to implement, if more than a sketch of an algorithm is required. A lot of it tends to come down to whether or not the candidate knows the shortest path and graph traversal algorithms, is familiar with cycle types and detection, and whether they know the complexity bounds. I think a lot of questions about this stuff comes down to trivia more than on the spot creative thinking ability.
I think problems related to trees tend to cover most of the difficulties of graph questions, but without as much code complexity.
I like the Project Euler problem that asks to find the most expensive path down a tree (16/67); common ancestor is a good warm up, but a lot of people have seen it. Asking somebody to design a tree class, perform traversals, and then figure out from which traversals they could rebuild a tree also gives some insight into data structure and algorithm implementation. The Stern-Brocot programming challenge is also interesting and quick to develop on a board (http://online-judge.uva.es/p/v100/10077.html).
Follow up any question like this with: "How could you improve this code so the developer who maintains it can figure out how it works easily?"
Implement a function that, given a linked list that may be circular, swaps the first two elements, the third with the fourth, etc...
I like to go over a code the person actually wrote and have them explain it to me.
Asking them to write a recursive algorithm for a well known iterative solution (i.e. Fibonacci etc. -- we give them an iterative function, if needed) and then have them compute the run time for it.
Many times the recursive function involves a tree data structure. The number of times the person has failed to recognize that baffles me. It becomes slightly difficult to calculate the run time until you can see that it's a tree structure...
I find that this problem covers many areas. Namely, their code-reading ability (if they are given an iterative function), code-writing ability (since they write a recursive function), algorithm, data-structure (for run-time)...
A trivial one is to ask them to code up a breadth-first search of a tree from scratch. Yeah, if you know what you're doing it is trivial. But a lot of programmers don't know how to tackle it.
One that I find more useful still is as follows. I've given this in a number of languages, here is a Perl version. First I give them the following code sample:
# #a and #b are two arrays which are already populated.
my #int;
OUTER: for my $x (#a) {
for my $y (#b) {
if ($x eq $y) {
push #int, $x;
next OUTER;
}
}
}
Then I ask them the following questions. I ask them slowly, give people time to think, and am willing to give them nudges:
What is in #int when this code is done?
This code is put into production and there is a performance problem that is tracked back to this code. Explain the potential performance problem. (If they are struggling I'll ask how many comparisons it takes if #a and #b each have 100,000 elements. I am not looking for specific terminology, just a back of the envelope estimate.)
Without code, suggest to make this faster. (If they propose a direction that is easy to code, I'll ask them to code it. If they think of a solution that will result in #int being changed in any way (eg commonly order), I'll push to see whether they realize that they shouldn't code the fix before checking whether that matters.)
If they come up with a slightly (or very) wrong solution, the following silly data set will find most mistakes you run across:
#a = qw(
hello
world
hello
goodbye
earthlings
);
#b = qw(
earthlings
say
hello
earthlings
);
I'd guess that about 2/3 of candidates fail this question. I have yet to encounter a competent programmer who had trouble with it. I've found that people with good common sense and very little programming background do better on this than average programmers with a few years of experience.
I would suggest using these questions as filters. Don't hire someone because they can answer these. But if they can't answer these, then don't hire them.