|
|
Pegs
I'm trying to decide how best to discuss this. I've come up with a reasonably elegant way to handle the connections between pegs, that allows you to easily see the next peg AND the peg beyond that, to test for possible jumps. I've also got a nice recursive algorithm to move the pegs around and search for solutions.
Recursion is great. A few for-loops and a recursive call, and something that before was difficult, now is simple. I'll post the results when I see it work as well as I think it should.
Meanwhile, I will talk about one odd little self-discussion I was having. It revolved around the typical OO quandry: what should be an object?
It came down to this: should I have a Board object that contains Holes? Or should the Board just have a few arrays to hold Hole information.
I had a Hole object for a while that had a boolean for peg/no-peg, and then an array of "neighbors", which pointed to other holes. I was really attracted to the cuteness of being able to say something like Hole h = otherHole.neighbor(1).neighbor(1); That kind of chaining is kinda neat to write, but it had two things I didn't like.
First, in setting up the board/holes, I really didn't want a networked chain of holes. That was unattractive to me, as the overhead to keep a dual-linked network of holes was a pain.
Second, and possibly more importantly, it didn't make sense that the Holes should know anything about their neighbors. Really, a Hole should just know if it has a peg or not. That's it. By putting the knowledge of the neighbors at Hole-level, that's where the structure of the board was kept. I had no structure in the Board, which is really not right. The Board needs to know what it looks like.
This became very obvious when I wanted to be able to create different kinds of solitaire boards. Some, like the familiar triangle, have six neighbors for each peg (like a hexagon), while others, like the cross, have only four.
I found though, that when I put the list of neighbors at the Hole level, that means I'd have to pass the number of neighbors to each Hole. Which again, seemed weird. The Hole shouldn't care, and should probably get that from the Board... but how would the Board convey it? It just didn't make sense.
So, instead, I put the list of connections/neighbors at the board level, in the form of an array [Holes,Neighbors]. This left the Hole just being a boolean that represented peg/no-peg, so I scrapped the whole Hole object and went with another array [Holes] of booleans, one for each hole.
Looking at it now, with the solution in hand, it seems so obvious. But it took me a bit of playing around to actually get there.
So, we'll see how the rest shapes up, hopefully by the end of the week. Once it's working in Java, I think I might try and get it working in .NET, either C# or VB, or both. Then, maybe Python. It'd be interesting to see it running in each language, I think.
Something Old, Something New
It's been coming for a long time. I've been trying to reach escape velocity and rocket away from my employer for a long time, but you know how it goes. The job starts to suck and that suckage combines with the overwhelming fear and dread of constant layoffs, so you decide it's time to get out and find something worth spending your time on. You throw yourself into the search, but then the job gets a little better and you think "Maybe it's not so bad. Maybe I can make it work here." So your search sort of peters off and you sink back into the mire of false hope.
Because finding a job is tough. Finding a job is a full-time job, and trying to do it part time and still be fair to the job you currently have is tough. And when you toss in a second full-time job (Dad), it's fairly unwieldy. So you hope things will work out where you're at, so you can concentrate on being successful.
But they didn't work out. Well, at least not for me. Things came to a head, and I took a Voluntary Job Elimination, which means my employer axes my job and my position. I get some layoff benefits, which made the decision easier, and now I can concentrate on finding the right job, full time. Also, as a side benefit, it's given me a little extra time for my second full time job (Dad, remember?), which has been great.
So, I'm hitting the virtual bricks, sending out resumes, making phone calls and doing research. I'm confident that I will find a job, and not just any job, but a good job. ("Good" here does not mean "high paying", but "spiritually satisfying". That's a long story that I will save for another day.)
Meanwhile, in order to keep my skills sharp and my resume attractive, and to build up a bit of a 'portfolio', I plan to tackle some projects in both Java and Python. One would be working through the Design Workbook as I mentioned below, but there are some other things I want to try as well. My first task will be to build a program to solve those triangle peg-jumping solitaire games. It's not a simple task, as the grid is a triangle, so a regular array won't cut it. I'll have to think of something clever, which is of course the fun of it.
I'll publish the results (and possibly the code) when I've got it working.
Oddly enough, I actually solved one by hand the other day. Here's the solution I found, numbering the holes from 1 at the top through 15 on the lower right:
With the hole at 1, move these pegs: 4 9 11 12 3 14 2 10 1 7 6 12 15
This should leave you with a single peg at 13.
|
|
|
|
