Those who’ve been following the evolution of this library, will probably be familiar with the SwitchInput class. It was intended (among other things) to provide functions that would only be called when a physical switch was closed or opened. The EventHandler class is similar, except that the conditions upon which the event is triggered are configurable and the function isn’t limited to running a single loop when the event occurs. I actually considered re-writing the SwitchInput class to be more like this, but given that it might break programs that people had written with it, I opted not to. Perhaps I’ll create a replacement in the future. Like SwitchInput, EventHandler is drived from the Thread class, with the loop() function overwritten. In its place are two protected virtual functions: condition() and on_event().

The condition() Function:

This is the function that is used to determine when the event is to be triggered. Basically, while the EventHandler object is idle, this function will be called every time the object is invoked by a ThreadList object. If it returns true, the event will be triggered, but if it returns false, the handler will remain in an idle state (this is one of those cases where I wish C++ supported lambdas (but that may be the LISP programming I’ve been doing talking (it’s hard to tell, really))).

The on_event() Function:

Once the event has been triggered, instead of calling the condition() function, the on_event() function will be called in its place. This can be thought of as a conditional loop() function. The difference being that when it returns false the handler will return to an idle state and wait for the condition() function to return true again rather than destroying itself.

A Note about kill_flag:

With a regular Thread object, the loop() function is expected to watch the kill_flag value. When it is set to true, the loop() function is is expected to terminate gracefully. As a help, this functionality is already built into the EventHandler::loop() function. If the handler is in an idle state, it will automatically terminate itself on its next call, however it may be advisable to have the on_event() function watch for this value so that it can facilitate a graceful termination (although, this is not strictly required as the handler will be terminated when the function returns false).

While I don’t feel I’ve done anything particularly ground-breaking with this new release, I hope I’ve created an adequate framework for other Arduino developers who don’t want to re-invent the wheel. As usual, I’ve made all the code and documentation available for this version.

Happy Hacking!

After some discussion in the comments of my last entry, I decided that my next attempt should be to add a check after every move to make sure that I hadn’t boxed any positions in, making them unreachable.

I almost dismissed this idea because I originally thought that it would involve checking every position on the board after every move, but it’s only necessary to check the eight positions that can be moved to from the current one.

The end result was this: on a 7×7 board, I can now compute the same path in 614 iterations as opposed to the 4430 required before. This represents an efficiency increase of slightly better than 720% (although that admittedly doesn’t account for the overhead added to each iteration by the check itself). An 8×8 board still takes an unknown amount of time however.

The thing that this check doesn’t take into account is the fact that there could be a cluster of positions that can reach each other, but can’t be reached from outside; as opposed to a single, isolated position. I had thought of this before I implemented the check, but hoped that it wouldn’t be a significant problem. It now seems that it may be.

It would seem that the next step is to find a way to look for clusters of isolated positions, although I haven’t yet quite decided how to go about that from a programming standpoint. Whatever I do, I’ll have to make sure that the checking process itself is as efficient as possible.

More details as I make more progress. As usual, here’s the source and documentation.

EDIT – 13 Feb 2011:
The source and documentation for this version were lost. I was able to recover the source (without doxygen comments) from Google’s cache, but I had to re-write much of the documentation. The code is now hosted at GitHub.

If we increase the size of the board to 6×6, we don’t even use up 1% of the possible permutations and the result is still calculated in an imperceptibly small amount of time.

By the time we increase to 7×7, we’re still using less than 1% (I’m assuming much less) of the possible permutations, but the result takes a few fractions of a second to calculate.

At 8×8 it gets really interesting. The gauge still doesn’t register (as expected) but I let the program run for about a minute or so with no result.

This would seem to indicate that as the size of the board increases, the percentage of permutations that we need to exhaust decreases (I’m assuming exponentially) but the amount of time needed increases (also exponentially… which I kind of expected).

From this we can extrapolate that at a size of 10×10, I will probably die before the program reaches a conclusion. If there’s a better way of calculating this it’ll either involve a radical optimization of the existing program or (more likely) writing a new one from scratch.

Once again, here’s my code and documentation.

As a matter of interest, I left the original program running in the background. We’re currently sitting at 18+ hours with (surprise) still no result.

EDIT – 13 Feb 2011:
The source code and documentation were lost. I found the source cached on Google (it’s now hosted at GitHub) and regenerated the documentation.

1. be given a starting position and the number of moves already completed successfully (zero on the first call – obviously)
2. return true if the number of successful moves already completed would fill the entire board
3. make sure that the position is within the boundaries of the table (retuning false on failure)
4. make sure that position was unoccupied (check that the corresponding value in the array is zero – again returning false on failure)
5. change the value at that location of the array to the current number of moves completed
6. call the function again with starting positions for each legal move with the new number of successful moves
7. as soon as one of these functions return true, the function would then return true itself
8. if no paths were found (all of the functions returned false) the function would then set the value in the array back to zero and return false itself

This table could then be displayed on the screen showing the calculated path.

I wrote a program to do this in about 15 minutes, but the problem is that it takes forever to calculate a path. At present, the program has been running for over 16 hours and still hasn’t come to a conclusion, nor do I even know how close it is to even getting to one.

Naturally, I wanted to rule out programmer error, so I adjusted the size of the board to 5×5 and ran it. This is what I got back instantaneously:

   1    6   15   10   21
  14    9   20    5   16
  19    2    7   22   11
   8   13   24   17    4
  25   18    3   12   23

This indicates to me that the code works, it just takes a long time to run through all the possible permutations.

I’ve posted the C source to my first attempt here and the documentation here.

Hopefully someone can help me find a faster solution, or I can find it myself.

EDIT – 13 Feb 2011:
The source code and documentation were lost. I found the source cached on Google (it’s now hosted at GitHub) and regenerated the documentation.