For completeness, the solution I ended up using was to pop! a coin from the
list, then call the method recursively *twice* - once for the case when the
coin is used (and the recursive total is thus reduced by the coin’s value)
and one where it’s not (and the total stays the same). Before
The algorithm I want to implement is fairly simple - it's a basic change
making problem: "given the following coins [20 coins with integer-values
between 1 and 50] how many ways is there to combine them to get a total
value of 150? two coins with equal value contribute one time each to a
Tomas
I don't think that what you envision can be implemented efficiently. After
a few steps, there will be an essentially arbitrary mapping between the
current and the original indices. Each time an index is removed, you'll
have to copy O(N) indices, or O(N) array elements.
However, there may
Hi
Can you use a macro to produce your twenty nested loops?
Oh man, fun puzzle. Even without the allocations, SubArrays that depend
upon an indexing vector (that is, not computable range) are really quite
slow since there's a lot of indirection at every element access.
You can solve the all-but-one problem with a custom view type fairly easily:
