|
|
|||||||||
|
|||||||||
| |||||||||
|
|
|
| |||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
|
|
You eat, breathe and sleep innovation. Build your mobile intelligence with BlackBerry® experts this July. Register Today! |
|
#1
|
|||
|
|||
|
Peg contest updates
So, now that the event is over, I was wondering if anyone has continued to work on their program. I know most people probably worked on it for long enough before hand that they probably don't want to see it any more. But, I didn't work on mine for very long and I'm finding that from looking at what other people did and combining some different ideas and fixing the bugs I had, that my program is getting better and better. Some things I've noticed now:
1. My program usually finds the lowest # of pegs it will find right away (within the first 1000 recursions of the searching function). 2. It chooses the correct path almost all the time on it's first try. So has anyone else continued to refine their program or just me? |
|
#2
|
|||
|
|||
|
RE: Peg contest updates
Your point 2 says it almost always finds the correct path first try. So why does it take a thousand iterations to find the solution? And what enables it to find the correct path straight away?
|
|
#3
|
|||
|
|||
|
RE: Peg contest updates
That's a good question, so what is your criteria now that allows you to choose the correct path right away?
|
|
#4
|
|||
|
|||
|
RE: Peg contest updates
Perhaps I stated that improperly. It's not that I always find the answer, my program still doesn't get them all right. What it does do is when it gets them right, it almost always gets them right without having to backtrack. Meaning if there's 27 pegs on the board, it makes 26 moves and that's it.
I setup my program with a heuristic function to try and cut down on the number of paths necessary. Basically, it looks at the board and gives it a score based on how the pegs are setup. It gives boards with pegs at the corners a worse score than with pegs in the middle. The concept being that pegs in the middle are easier to get rid of. It then looks at every possible move on each step and picks the one with the best score and goes down that path. With my revisions, I have been able to get it to about 4000 states/second on my athlon 1600. Not sure what the hardware was that ran the contest so I don't know how that compares to what I was doing before, really. Anyways, what I should have said is that if it's going to get it right, it does it right away and rarely makes even a single incorrect guess. It does, however, still make incorrect guesses. That could possibly be eliminated with a better heuristic scoring function. Anyone have any ideas on that? |
|
#5
|
|||
|
|||
|
RE: Peg contest updates
Mungk: You should try applying your heuristic to xs0's code to what speed you can gain. I haven't looked at your entry, but xs0's sorts the branches from least moves to most moves, then recurses. If you ordered the branches according to your score, it may find solutions very fast.
Just a thought. |
![]() |
| Viewing: Codewalkers Forums > PHP Contests > Older Contests > Peg contest updates |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
|
|
|
|
|