Refactoring Siteswap

One of the coolest things about my apprenticeship at 8th Light is that I have the opportunity to pick lots of brains and learn how different craftsmen approach problems. Last Friday, I explained my siteswap problem to Li-Hsuan and we worked on the problem of efficiently removing arrays with repeating patterns. For example...

• 1234512345 shouldn't exist. 12345 is fine.
• 123123123 should just be 123
• 121212 should be 12
• 333 should be 3

You get the idea. He pointed out that you could get away with fewer calculations if you start with an array that's cut in half and then check the two halves, rather than starting with the smaller divisor and working your way up. For example, 123123123123 could be checked by a sub-string length of [1], then checked by [12], then checked by [123] (which would then return true because it's a repeating pattern)...or it could be checked once by [123123][123123]. Checking the larger divisor first will usually be more efficient.

Then I asked Colin to help me figure out why it takes so long to calculate longer sequences. I initially thought that it had something to do with my correct_timing method, but we soon discovered that it was actually Ruby's repeated_permutation function that was taking so much time to run. We talked about the potential of making a lazy method to return a smaller number of values, but I'm not sure if it's possible in this scenario. If I decide to turn this into a web app, I might need to pre-generate the values and then have the app run checks against an already-established list of possible throw sequences for different throw heights, number of juggling props, and number of throws in a sequence.

In the meantime, I implemented inclusion and exclusion functionality so that users have greater control over what types of values are returned.

And yes, I'm still pushing changes to GitHub.