Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I hear people say a lot of times recursion can be an “endless loop”, but wouldn’t that saying be only applied to something done with loops. Would it be valid and correct to say “endless loop” for recursion like that? Wouldn’t it better to say “endless recursion”?
A tail recursion can be considered a iterative loop. This is the only type of infinite recursion that doesn't swiftly end with a stack overflow error.
If you write this in a compliant ECMAScript 2016 implementation
const test = (n) => test(n + 1);
test(0);
It will hang forever and never cause a stack overflow. The browser will hang as it is a busy loop, but it will never get a stack overflow because tail calls are optimized into something like this:
const test = (n) => {
while(true) {
n++;
}
}
test(0);
If you consider the bottom one an infinite loop, the first one is not different.
If this was C both would be turning into very similar assembly code using gotos, because assembly does not have while loops nor functions.
Related
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 last year.
Improve this question
I just stumbled upon some OCaml code that writes a loop like this:
let r = ref (f 0) in
for i = 1 to k - 1 do
r := f i * !r
done ;
!r
in
Which is interesting as I normally see this done using recursive functions in OCaml usually. Is there an advantage to one versus the other?
It is a matter of style nothing more. OCaml enables both pure functional and pure imperative style and lets the users choose what suits their needs.
In this particular example, the same implementation that uses the recursive function will have the same performance (and basically will be compiled to the same code). In more complex examples, when the reference is storing not an immediate object (i.e., when it is stored in the heap), the imperative loop might be slower than a pure recursive function as the former will involve a write barrier on each update.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
Can anyone please help me with this , How is the DP's Iterative approach different from the Recursive Approach.
Dynamic Programming and Recursion aren't necessarily opposites. What you're thinking is Memoization vs. Dynamic Programming.
Dynamic Programming is the approach to a problem that reduces duplicate computations as much as possible. This usually means taking a bottom-up approach - i.e. you calculate answers to smaller scale problems first and then use those answers to calculate higher order problems. Iterative approaches are usually used for Dynamic programming since it seems natural (although you can do it recursively too).
Memoization is the top-down approach to a problem and is usually done through recursion because it is more natural. In this case, you start with a higher order problem and make recursive calls for lower order problems in order to solve it.
In both cases you use a data-structure to store values computed so far.
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 6 years ago.
Improve this question
So we just finished the subject recursion in school and I am still wondering "why?".
I feel like I have just learned a hell of a lot about math in a programming way with the sole purpose of passing an exam later on and then never again.
So what I want to know is when to use it? I can only find people saying "when you want to call a function within itself" but why would you do that?
Recursion is the foundation of computation, every possible program can be expressed as a recursive function (in the lambda calculus). Hence, understanding recursion gives you a deeper understanding of the principles of computation.
Second, recursion is also a tool for understanding on the meta level: Lots of proofs over the natural numbers follow a pattern called "natural induction", which is a special case of structural induction which in turn allows you to understand properties of very complex systems in a relatively simple way.
Finally, it also helps to write good (i.e. readable) algorithms: Whenever there is data to store/handle in a repetitive calculation (i.e. more than incrementing a counter), you can use a recursive function to implicitly manage a stack for you. This is also often very efficient since most systems come with a machine stack at hand.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Can you please provide a specific situation illustrating when a for loop might work more effectively than the more commonly cited apply suite of solutions?
If the results of the previous computation are used in the next computation, it is appropriate to use a for loop, since this behavior is difficult to replicate with lapply (you would have to use something like Reduce). R is not necessarily slow with for loops, merely with memory allocation (which is easy to get wrong with for loops). See Chapter 2 of the R Inferno.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I heard this a lot when talking about software engineering and abstract data types, what does this do? Can anyone give me a concrete example of this concept?
A representation invariant is a condition concerning the state of an object. The condition can always be assumed to be true for a given object, and operations are required not to violate it.
In a Deck class, a representation invariant might be that there are always 52 Cards in the deck. A shuffle() operation is thus guaranteed not to drop any cards on the floor. Which in turn means that someone calling shuffle(), or indeed any other operation, does not need to check the number of cards before and after: they are guaranteed that it will always be 52.