I’m trying to reduce the time and space needed by the Knapsack DP algorithm with non-integer values.
http://en.wikipedia.org/wiki/Knapsack_problem#Meet-in-the-Middle_Algorithm
In particular, if the [elements] are nonnegative but not integers, we could
still use the dynamic programming algorithm by scaling and rounding (i.e. using
fixed-point arithmetic), but if the problem requires fractional digits of
precision to arrive at the correct answer, W will need to be scaled by 10^d,
and the DP algorithm will require O(W * 10^d) space and O(nW * 10^d) time.
The DP knapsack algorithm uses a [ n x W ] matrix, filling it up with results, but some columns never get filled – they do not match any combination of object weights. This way, they simply end up filled with zeros on each row and just waste time and space.
If we used an array of hashes instead of a matrix, we could reduce the time and space needed.
edit:
knapsack capacity = 2
items: [{weight:2,value:3} ]
[0 1 2]
[0 0 0]
2: [0 0 3]
^
Do we need this column?
Substitution with hash:
2: {0:0, 2:3}
In Python, dict insertion has a O(n) worse case and an O(1) “amortized” linear time.
Am I missing something?
What would be the complexity of such a variation on the knapsack DP algorithm ?
What you speak of is, if I can say that, happy cases – cases in which you have very little number of items to insert in a knapsack with huge volume. In this case hashmap can prove to be optimization triggering the complexity from
O(W * n)to justO(min(O(2^n * n), O(W * n)))(2^nis the number of combination of the n elements). However, with this estimation it is obvious that for not that big number of elements, theO(2^n * n)will dominate the other estimation. Also, note that whilst theO(W * n)are of the same class, the constant in the latter case is significantly greater (and even more: the estimation in the second case considers amortized complexity, not worst case).Thus you get that in certain cases the hash map might prove to be better, but in the common case the opposite holds true.