fork-ledger.git -

	Commit message (Collapse)	Author	Age	Files	Lines
*	Fix typos found by codespell	Alexis Hildebrandt	2022-07-19	1	-1/+1
\|
*	Sort solution by date in output.	Bradley M. Kuhn	2013-02-18	1	-1/+1
\|
*	Searching is better when you can set the begin date, end date and then go ↵	Bradley M. Kuhn	2013-02-18	1	-6/+6
\| \| \| \|	back from begin date.
*	Improve spreadsheet and debugging output.	Bradley M. Kuhn	2013-02-18	1	-6/+10
\|
*	Start search from date: easy way to resume searches.	Bradley M. Kuhn	2013-02-18	1	-5/+5
\| \| \| \| \| \|	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).
*	Finish reporting details for STDOUT; change command line arg to bank balance.	Bradley M. Kuhn	2013-02-18	1	-20/+40
\| \| \| \| \| \| \|	Report in CSV now goes to STDOUT. The command line argument that was the difference to seek is now the bank balance.
*	Default to brute-force subset sum solution.	Bradley M. Kuhn	2013-02-18	1	-8/+44
\| \| \| \| \| \|	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.
*	Rename the function to note it's the dynamic programming one.	Bradley M. Kuhn	2013-02-18	1	-2/+2
\|
*	Loop through to build smaller sets when testing.	Bradley M. Kuhn	2013-02-18	1	-29/+52
\| \| \| \| \| \| \|	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.
*	Basic implementation probably correct, but needs much RAM.	Bradley M. Kuhn	2013-02-18	1	-9/+36
\| \| \| \| \|	This is the basic implementation but for large numbers, it needs a LOT of RAM.
*	Began work on script to reconcile bank accounts.	Bradley M. Kuhn	2013-02-18	1	-0/+122
	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: https://gitorious.org/bkuhn/small-hacks/commit/2dca069d810b61cdfad46e00abcb1a3edaf56d1b 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.