Probably yes!

First let's make a clear (well, not so clear) difference, clearer. Dynamic Programming is not about Dynamic Typing. Dynamic typing is a property of a particular programming language. Languages like Lisp, Python, and Ruby are all dynamically typed languages. Unlike those, languages like C/C++, Java, and C# are statically typed language. The difference relies on whether the compiler checks certain things (types, overload resolution, etc.) before running the program or not.

Dynamic Programming on the other hand is something very different. It's an ancient method for solving problems by basically dividing these problems into smaller, and easier to solve problems.

It's mainly focused on addressing these two issues:

- Overlapping subproblems
- Optimal Substructures

I think the best way to explain these two fuzzy concepts is by using examples. To start let's see an example of using a famous dynamic programming technique called Memorization. Assume that we need to implement a function that calculates a Fibonacci sequence. I know this is easy, but let's look at this first implementation:

static int FibClassic(int n, ref int numberOfStepsTaken) { numberOfStepsTaken += 1; if (n <= 1) return 1; Console.WriteLine("FibClassic called with: {0}", n); return FibClassic(n - 1, ref numberOfStepsTaken) + FibClassic(n - 2, ref numberOfStepsTaken); }Note: on the above code I used two counter variables to count the number of times the method executed. I also printed the input on which the method is called every time, just to give you a hint of how dividing a problem can cause the same subproblem to be computed more than once --Subproblem Overlapping, remember! Now let's run the code given the number 6 as input and see what happens:

int z = 0; int x = FibClassic(6, ref z); Console.WriteLine("{0}: {1}", x, z);

As you can see the method has been called first with input 6 which is the initial input we passed in, then 5, 4, 3, 2, 2, ... oops!! Can you spot it? the method is being called on the same input more than once! Think about this for a while, pretty logical, yeah!? Our strategy is based on dividing the problem into simpler subproblems. For example to get the 6th item in the Fibonacci sequence we divide the problem into two smaller problems, getting the 5th item, and 4th item and adding them together, then to get the 5th, you should get the 4th and 3rd, etc. The next figure shows how is this working.

static int FibFast(int n, ref int numberOfStepsTaken, DictionaryIf you run that same method on the same input (6) you should get 13 as the result (the same old result) but the number of iterations would be 11 which is about half the number of iterations the first method take. This doesn't seem to be a very huge enhancement, but let's see how the two methods act for bigger numbers. Running the first method of input equals to 30 we get the result 1346269 and number of iterations 2692537. Now running the second method on the same input (30) we get the result 1346269 -which is the same result- and number of iterations 59! That's astore) { numberOfStepsTaken += 1; if (n <= 1) return 1; if (!store.ContainsKey(n)) store[n] = FibFast(n - 1, ref numberOfStepsTaken, store) + FibFast(n - 2, ref numberOfStepsTaken, store); return store[n]; }

**HUGE**difference!

**Now back to core, what does this have to do with the term Dynamic Programming??**

*Actually, it's a very misleading term, historically it was invented by a mathematician called*

**Bellmen**and he was at the time being paid by the US defense department to work on something else. He didn't want them to know what he was doing, so he made up a name that he was sure it has no clue what it actually meant. Now we have to live with this forever :)
## 2 comments:

You have just done a top-down dynamic programming. It might be instrutive to do a bottoms-up dynamic programming where you store answers from 1 to n in your store (in that order as opposed to storing just what you need in the top-down approach). Since this looks like C#, using iteration over recursion and use a vector to maintain your key-value store, you will probably give you a much better performance.

@kink, you are right, the iteration solution would result in a much better performance, and it's probably the best way to do it. However, I introduced this recursive implementation here just for demonstration purpose.

Post a Comment