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.
Related
Currently learning about the A* search algorithm and using it to find the quickest solution to the N-Puzzle. For some random seed of the initial starting state, the puzzle may be unsolvable which would result in extremely long wait times until the algorithm has search the entire search-space and determined there is not solution to the give start state.
I was wondering if there is a method of precalculating whether the A* algorithm will fail to avoid such a scenario. I've read a bit about how it is possible but can't find a direct answer as to a method in which to do it.
Any guidance or options are appreciated.
I think A* does not offer you a mechanism to know whether or not a problem is solvable. Specifically for N-Puzzle, I think this could help you to check if it can be solved or not:
http://www.geeksforgeeks.org/check-instance-8-puzzle-solvable/
It seems that if you are in a state where you have an odd amount inversion, you know for sure the problem for that permutation is infeasible.
For the N-puzzle specifically, there are only two possible parities, so you just need to check which parity the current puzzle is.
There is an in-depth explanation on how to do this on the math stackexchange
For general A* problems, no, there is no way to pre-compute if the graph is solvable.
I wasn't entirely sure the best way to ask this question (or do the research to see if it has been previously answered).
Given a data set where each entry has a Point value and a Dollar value, I'm looking to generate a list of length N entries that yields the highest aggregate Point value whilst staying within budget B.
Example data set:
Item Points Dollars
Apple 3.0 $1.00
Pear 2.5 $0.75
Peach 2.8 $0.88
And with this (small) data set, say my budget (B) is $2.25, and list length (N) must be 2. You MUST use the fixed list length, but are not required to use ALL of the budget.
Obviously the example provided is easy to do in one's head, but given a much larger data set, and both higher N and B values, I'm looking for an algorithm that can generate the list. Having a hard time wrapping my head around this one.
Just looking for a pseudo-algorithm, but if you prefer any given language feel free to respond with that!
I am quite positive that this can be reduced to an NP-complete problem and hence it's not really worth trying to develop a process that will always give you the 'correct' answer as many people have tried and failed to do this efficiently over a large data set. However, you can use a much more efficient approximation technique that whilst it will not guarantee to give you the correct answer, many popular approximation algorithms are capable of achieving a high degree of accuracy.
Hope this helps you out :)
This problem is NP-Complete (NP and NP-Hard), meaning, that until now there is no algorithm found, that solves this problem in a polynomial amount time (polynomial to the input size) and if you find an algorithm that does, you would have solved one of the greatest problems in computer science (P=NP), which would you at least bring a million dollar reward.
If you are satisfied with an approximation, I would recommend the Greedy-Algorithm:
https://en.wikipedia.org/wiki/Greedy_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.
I am struck very badly in a problem. my problem goes this way; I need to find permutations of n objects(there could be repetitions) such a way that every permutation differs from the other by atleast k objects.
For ex: if there are 5 objects a,b,c,d,e and each permutation differs by 2 or more object and if aabcd is a permutation then I cannot have aabdd as a permutation as both differ by just one object.
If anyone can point me out a general formula or procedure to solve this problem, I'd be highly grateful
Thanks for your time and consideration of this request
--Ady
This sounds like it's related to Conway's Lexicode thereom. I heard him give a lecture about it once. It was quite entertaining.
http://www.dpmms.cam.ac.uk/seminars/Kuwait/abstracts/L25.pdf
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.