Knapsack formula using only weights as the recursion variable - algorithm

I have developed a recursive formula for knapsack problem on my own without any knowledge of present solutions. Please tell me whether it is right or wrong and correct it.Thanks in advance.
B(S) = max (B (s-w(i)) + b(w(i)) )
for all i belonging to n;
notations are as usual . S is capacity,B is the answer to knapsack.

I do not want to give you straight answer, but to direct you on the flaws of your formula, and let you figure out how to solve them.
Well, if you do not address the value, something must be wrong - otherwise, you just simply lose information. If you chose to "take" the item (B(s-w(i))) what happens to the current value?
In addition, what is i? How do you change i over time?
When talking about recursive formula, you must also mention a stop clause for it.

Related

Forced-Directed-Graph Fruchterman and Reingold t and disp (number and vector?)

I am trying to implement the algorithm of Fruchterman and Reingold and have a problem in understanding the types of the "t" (temperature) and "disp" (displacement) because on the last loop they calcualte the minimum of t and disp. Is t not a number and disp a vector? How can I calculate the minimum of a number and a vector?
Link: www.cs.brown.edu/people/rtamassi/gdhandbook/chapters/force-directed.pdf#page=5
As a disclaimer, I have no previous experience of this algorithm, but it seems to me as if you are right and that this is a typo, where actually min(|v.disp|, t) was meant.
I find some support for my claim looking at an implementation here, which recognises some typos in the original pseudo-code. Please verify yourself before taking my word for it.

Defining a special case of a subset-sum with complications

I have a problem that I have a number of questions about. First, I'm mostly looking for help describing and understanding the problem at hand. Solutions are always welcome, but most importantly I could use some advice from someone more experienced than I. Now, to the problem at hand:
I have a set of orders that each require some number of items. I also have several groupings of items that each contain some number of some items (call them groups). The goal is to find a subset of the orders that can be fulfilled using as few groups as possible and where the total number of items contained within the orders is between n and N.
Edit: The constraints on the number of items contained in the orders (n and N) are chosen independently.
To me at least, that's a really complicated way of saying the problem so I've been trying to re-phrase it as a knapsack problem (I suspect this might reduce to a subset-sum). To help my conceptual understanding of this I've started using the following definitions:
First, lets say that a dimension exists for each possible item, and somethings 'length' in that dimension is the number of that particular type of item it either has or requires.
From this, an order becomes an 'n-dimensional object' where its value in each dimension corresponds to the number of that item that it requires.
In addition, a group can be seen as an 'n-dimensional box' that has space in each dimension corresponding to the number of items it provides.
An objects value is equal to the sum of its length in all dimensions.
Boxes can be combined.
Given the above I've rephrased the problem to this:
What is the smallest combination of boxes that can hold a combination of items with value between n and N.
Question #1: Is this a correct/useful way to express the problem? Does it seem like I've missed anything obvious?
As I see it, since there are two combinations that I'm looking for I need to break the problem into two parts. So far I think breaking the problem up like this is a good step:
How many objects can box (or combination of boxes) X hold?
Check all (or preferably some small subset of) the possible combinations of boxes and pick the 'best'.
That makes it a little more manageable, but I'm still struggling with the details.
Question #2: Solved To solve the first part I think it's appropriate to say that the cost of an object is equal to the sum of its length in all dimensions, so is it's value. That places me into a subset-sum problem, right? Obviously it's a special case, but does this problem have a name?
Question #3: Solved I've been looking into subset-sum solutions a lot, but I don't understand how to apply them to something like this in multiple dimensions. I assume it's been done before, but I'm unsure where to start my research. Could someone either describe the principles at work or point me in a research direction?
Edit: After looking at everyone's feedback and digging into the terms I think I've found a good algorithm I can implement to solve part 1. Since I will have a very large number of dimensions compared to the number of items it looks like using a 'primal effective capacity heuristic (PECH)' will be a good fit. I'd be interested in hearing someones thoughts about it if they have experience with such an algorithm.
Question #4: For the second part, performance is a concern and I doubt it will be realistic to brute force it. So I intend to treat all combinations of boxes as a really big tree of solutions. The idea is to compute part 1 for all combinations of M-1 boxes where M is the total number of boxes. Somehow determine the 'best' couple box combinations from that set and do the same to their child nodes on the tree. Does this sound like it would help me arrive at something close to optimal? How would I choose the 'best' box combinations?
Thanks for reading! Suggestions for edits and clarifications are welcome.

Greedy algorithm and coins algorithm

First, yes it's my HW and I find it hard so I'll really appreciate some guidance.
I need to prove that for denomination of 1,x,x2...xn when x>=1 the greedy algorithm for the coins problem always work .
We will always get the amount of money we need in minimal coins number when we always pick the maximal coin that smaller from the amount.
Thank you.
As this is your homework I will not provide a complete answer but will rather try to guide you:
First as it usually happens for problems of that type try and prove for yourself that the statement is true for the first few natural numbers. Try to summarize what you use to make the proof for them. This usually will give you some guidance of the correct approach.
I would use induction for this one.
Another option that might help you - represent all the numbers in numerical system with base x. This should make it clearer why the statement is true.
Hope this helps you.

Solution to Recursive Relations with Arrays

from Mexico. The truth is almost never asked or open new issues, because really the forum and not only this, if not to work instead of the network, you can find plenty of information about topic x or y, however this time I feel very defeated.
I have two years of recursion.
Define the following recursive algorithms.
a. Calculate the next n integers.
At first not referred to the master with this is that if the algorithm returns a sum, or set of numbers. Furthermore, although in principle and algorithm design for the second case is asked to resolve by its expression as a recurrence relation ... this is where I am more than lost, not how to express this as a RR. And that can be solved
b. Calculate the minimum of a set of integers
In the other case suppose that calls for the minimum of a set of integers. that's solved, but the fact and pass it to a RR fix, has left me completely flooded.
APPRECIATE ANY HELP, thanks
Answering on b)
You have a set of integers. You pick one and you know that minimal element is either that you've picked or the minimal is still in the set. Recursivly you call function unless you pick all elements from set, you assume that minimum of set that contain no elements is infinity. Then your recurrence is going back updateing the minimal value.
minimum (S) = min(any element, minimum(Rest of S))
if (S is empty) then minimum(empty) = infinity.
Not an implementation in any language cause surely depend on representation of set.
P.S why doing this recursivly?

Create a sum of 1000, 2000, etc. from set of numers

Ok, so here's the problem:
I need to find any number of intem groups from 50-100 item set that add up to 1000, 2000, ..., 10000.
Input: list of integers
Integer can be on one list only.
Any ideas on algorithm?
Googling for "Knapsack problem" should get you quite a few hits (though they're not likely to be very encouraging -- this is quite a well known NP-complete problem).
Edit: if you want to get technical, what you're describing seems to really be the subset sum problem -- which is a special case of the knapsack problem. Of course, that's assuming I'm understanding your description correctly, which I'll admit may be open to some question.
You might find Algorithm 3.94 in The Handbook of Applied Cryptography helpful.
I'm not 100% on what you are asking, but I've used backtracking searches for something like this before. This is a brute force algorithm that is the slowest possible solution, but it will work. The wiki article on Backtracking Search may help you. Basically, you can use a recursive algorithm to examine every possible combination.
This is the knapsack problem. Are there any constraints on the integers you can choose from? Are they divisible? Are they all less than some given value? There may be ways to solve the problem in polynomial time given such constraints - Google will provide you with answers.

Resources