I had an... unexpected... burst of productivity over the weekend and programmed a robust financial transaction manager.


Microsoft Money is overkill. I mean, god. It's so complex it's stupid. Hell, half the time when I enter all my debits into it, for some reason it can't compute it correctly (Hello, it's just adding numbers!!!) (And yes, I entered the numbers right, I quadruple-checked it). Pretty much the only thing I really love about MS Money is the graphs it generates. Those are awesome.


My other choice was Excel... which is underkill. It doesn't have enough of what I want in it to be useful.


So... I rolled my own solution, and after 2 days, it's actually pretty cool. I'm not done yet, but the base is there and working properly.

Features:

* 256 bit password-based encryption of data files
* Flexible category system that doesn't limit you to one category (unlike MS-Money)
* Customizable searches based on date, transaction amount, category, and others.
* Eventually it will have pretty graphs.



Screenshots!


This one shows a sample database sorted by date.



And one that sorts by account:


You can choose to filter transactions by account, date, category, and value, so you don't get spammed with 5 billion transactions after you've been using it for a while.


Here's the transaction data entry screen:


And the category system:



I'm considering moving the category system to some sort of tree-based hierarchy, so that when you select "Car Insurance", the "Car" category is automatically selected as well. This will take some reworking, but it will make the program 100% more user friendly.

At the moment, the category dialog filters the search by what you type in the box. In the screenshot, 'a' is typed in, so every category that has the letter 'a' in it is shown. If you typed 'Car', it would show everything that is related to cars.

I think I may end up trying to sell this online for $10-$20. Comments, opinions?


Other notes:

I got bored and wrote a program to solve John Hattans Voracity game. I'll stop using it now, because I'm bored of it and that's not really fair to everyone else. It took me less than an hour to write the solver in C#, and it can go through about 10 billion game states per day. It will eventually find a maximum solution, but so far I've never had the patience to run it that long. There's really no way to tell how many solutions there are overall, because the game is mutable, and changes the playing field with every move. This little fact makes the "Longest Path" algorithm even more difficult, since I wasn't able to divide and conquer, by using previously known longest-segments to shorten the search.

In a standard longest-path-scenic-tour algorithm, you can start at the endpoint and figure out which nodes take the longest to reach it, and work backwards from there. This doesn't work for two reasons, though; we don't know the endpoint until we reach the end of a solution, and even then, it's not garanteed to be the longest solution. So we've got 625 possible endpoints. Secondly, not all paths work their way back to the start anyways.

So the major problem exists with the mutability. Let's say the algorithm landed on X,Y in game state A and found that there are 20 possible paths from that point. Of those 20, we find that path B is the longest, so we can store "At X,Y, path B is the solution". In an unmutable game, this would greatly reduce the search space, but in Voracity, this can't be done. If another search reaches point X,Y again, we can't just say that B is the longest path, because the board can be totally different! In fact B may not even be a valid path anymore!

So any divide and conquer method is out.


I even experimented with some heuristic searches, but pretty much every heuristic search that doesn't closely follow a depth-first search will generate so many intermediate game states that you'll very quickly fill the entire memory of your computer.


For example: "search paths that consume the most squares per move first" generated so many child moves that I ran out of memory in 30 minutes.

"for each search, compute the value of the squares that are consumed, divide that by the number of squares that were consumed, and favor search paths that minimize this value"... this would have been a great search, if not for the fact that I ran out of memory in 4 minutes. (ie: if we have a choice between a path that consumes 5 squares that hold the number 9, or a path that consumes one square containing the number 1, we'd choose the second one first, since it only removes 1 potential consumption from the game, whereas the first path removes 45 possible consumptions from the game).


I ended up using "favor the longest immediate path first" heuristic.


This is still kind of inadequate though. This is because out of the first 8 initial moves, it takes over a day to compute just one of those paths, and if the first move is stupid, you'll never find a better path. For example, there was one case where I had a choice of a 9, and a bunch of lower numbers. The LIPF search chooses to search the 9 path first, since 9 is the longest, but it turns out that after the first move, the rest of the moves are disappointingly small. But we never would have found that out, because it would have spent the rest of the day searching subpaths of the first move.

So, I decided to combine the depth-first with a limited breadth-first search, and I compute the first 3 moves of the game (somewhere in the vicinity of 200-400 states, depending on the game). From those states, each one has its own queue, and it does a depth first search on each one, iteratively.


So, from my experimenting, I've found that it is computationally simple to find a good path (55-60%), and almost computationally impossible to find a perfect path.



By the way John, the bad news is that your randomizer will start repeating games. The good news is that this won't happen until the year 2643. :)