Instead of always starting a search from the end date, allow a CLI option
that is the data to use for the start of searching (back from the end date).
This is useful when resuming a search (since they take a long time).
The dynamic programming version of the subset sum problem required far too
much RAM for larger bank balances. Meanwhile, the brute-force is not to bad
now that the loop tries the closer dates *first*.
Usually, transactions that didn't appear are nearby in date to the statement
date. This loop cycles through. Overall, this would take longer to find a
solution, but since most solutions are in the early dates "back" from the
statement date, this will probably be faster in typical cases.
The goal here is to take as input an account, a monthly balance amount
that appears on a bank statement, and the date of that bank statement and
output the list of transactions that likely weren't cleared properly as of
that date that caused the balance in the accounts to fail to match the
balance that appeared on the statement.
Note that determining this answer requires solving the known NP-Complete
problem called the subset sum problem. There is a known pseudo-polynomial
dynamic programming solution to this problem, but it's still exponential
in the size of the numbers you have to balance.
So, if you have *big* account balances, this will make take quite a while
to run. For smaller accounts, the pseudo-polynomial solution might be
helpful. (BTW, the wikipedia entry on the subset sum problem isn't, at
the time of this commit, particularly good, but it's "good enough" to give
you a sense of what the subset sum problem is:
http://en.wikipedia.org/wiki/Subset_sum_problem
)
I originally wrote the subset sum problem solution implementation here:
2dca069d81
The code is just cut and pasted in here with some minor modifications.
This rest of this first commit just has that aforementioned paste, plus the
beginnings of the CLI and query to run to get the proper entries.
