Rob Oplawar
January 20th, 2010, 03:15 PM
Ok, over Christmas break I was looking through my notebook and I found this mysterious algorithm, written in my own handwriting (see first image). I was intrigued, as I couldn't remember writing this algorithm. Now, I am completely perplexed, as I cannot figure out what the fuck the algorithm does.
I will briefly summarize it in pseudocode here:
int[] M = {2,4,7,8,14,16,28,56} // these are all the divisors of 112, discounting 1 and 112.
function[] F = {function pointers...}
// this is an example of an F function (each one has the same interface):
boolean f(by reference: int j, by reference: int k, int[][] input) {
if(++k >= input[k].size) {
k = 0;
if(++j >= input.size) {
return false;
}
}
return true;
}
// each of those functions provides a different path to step j and k through the 2D input array
// when the function finishes stepping through the whole 2D array, it returns false
int[] solve(int m, function f, int[][] input) {
int i = j = k = l = 0
int[] result = {0}
do {
result[i] += (input[j][k] * (2^l))
if(++l > m) {
l = 0
i++
result[i] = 0
}
} while( f(j, k, input))
return result
}
int[][] input = // input is some unknown 2D array of integers
for each M as m {
for each F as f {
// no idea what to do with the output
print solve(m, f, input)
}
}
Yes, I know the variable names are god-awful. That's what's written in my notebook. I'm just as stumped about what each one is for as you are.
The lines of interest are
int[] M = {2,4,7,8,14,16,28,56}
and
result[i] += (input[j][k] * (2^l))
As I said before, M is all the divisors of 112. What is special about 112? No clue. In binary it is written as 1110000, which almost seems significant, but could just as easily be meaningless. It seems to have something to do with factorization, but I have no clue.
Then it's tracking sums of values from the input array times two to the l, which is an integer from 1 to m at any given time. I just realized that what this is effectively doing is shifting the bits by one position on each addition; this seems like a key aspect to the algorithm.
The real head-scratcher is what the fuck is the input? The input probably has some sort of significance, ie, I suspect this algorithm wants to do something very specific for a very specific input. I can almost recall writing this, and there's some memory of searching for an optimal solution among the different F implementations- different paths for traversing the input.
On my tests I've used an input that looks like
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
but that's completely arbitrary.
For m = 2, f = [the example implementation shown above], and input = [sample input shown above], the output of solve is
17, 38, 59, 80, 101, 16.
... *shrugs*
So, there's a slim chance that I actually wrote this algorithm when I was either asleep or drunk off my ass. The handwriting seems too legible for either of those, but you never know. This could just be a bunch of gibberish. I don't think it is, though. It seems very structured and very deliberate. It definitely does *something*! Then again, even when I'm perfectly sober I tend to make mistakes in the first draft of my pseudocode. The algorithm here could have some specific purpose but entirely fail to achieve that purpose because of some mistake. How can we tell what was intentional from what wasn't?
Arglblarbl, this is driving me crazy!
http://hphotos-snc3.fbcdn.net/hs125.snc3/17256_810459615373_10240225_46642246_5176962_n.jpg
The original algorithm as found in my notebook. I have no recollection of when or why I wrote this. Note the little zig-zags at the bottom- those are visual representations of the way the different F functions advance j and k through the 2D array.
http://photos-d.ak.fbcdn.net/hphotos-ak-snc3/hs145.snc3/17256_810459839923_10240225_46642249_1708824_n.jpg
I transcribed it all onto the whiteboard in the CSEL. Hopefully someone will come by and instantly recognize the algorithm's purpose so I can stop going crazy.
I will briefly summarize it in pseudocode here:
int[] M = {2,4,7,8,14,16,28,56} // these are all the divisors of 112, discounting 1 and 112.
function[] F = {function pointers...}
// this is an example of an F function (each one has the same interface):
boolean f(by reference: int j, by reference: int k, int[][] input) {
if(++k >= input[k].size) {
k = 0;
if(++j >= input.size) {
return false;
}
}
return true;
}
// each of those functions provides a different path to step j and k through the 2D input array
// when the function finishes stepping through the whole 2D array, it returns false
int[] solve(int m, function f, int[][] input) {
int i = j = k = l = 0
int[] result = {0}
do {
result[i] += (input[j][k] * (2^l))
if(++l > m) {
l = 0
i++
result[i] = 0
}
} while( f(j, k, input))
return result
}
int[][] input = // input is some unknown 2D array of integers
for each M as m {
for each F as f {
// no idea what to do with the output
print solve(m, f, input)
}
}
Yes, I know the variable names are god-awful. That's what's written in my notebook. I'm just as stumped about what each one is for as you are.
The lines of interest are
int[] M = {2,4,7,8,14,16,28,56}
and
result[i] += (input[j][k] * (2^l))
As I said before, M is all the divisors of 112. What is special about 112? No clue. In binary it is written as 1110000, which almost seems significant, but could just as easily be meaningless. It seems to have something to do with factorization, but I have no clue.
Then it's tracking sums of values from the input array times two to the l, which is an integer from 1 to m at any given time. I just realized that what this is effectively doing is shifting the bits by one position on each addition; this seems like a key aspect to the algorithm.
The real head-scratcher is what the fuck is the input? The input probably has some sort of significance, ie, I suspect this algorithm wants to do something very specific for a very specific input. I can almost recall writing this, and there's some memory of searching for an optimal solution among the different F implementations- different paths for traversing the input.
On my tests I've used an input that looks like
1 2 3 4
5 6 7 8
9 10 11 12
13 14 15 16
but that's completely arbitrary.
For m = 2, f = [the example implementation shown above], and input = [sample input shown above], the output of solve is
17, 38, 59, 80, 101, 16.
... *shrugs*
So, there's a slim chance that I actually wrote this algorithm when I was either asleep or drunk off my ass. The handwriting seems too legible for either of those, but you never know. This could just be a bunch of gibberish. I don't think it is, though. It seems very structured and very deliberate. It definitely does *something*! Then again, even when I'm perfectly sober I tend to make mistakes in the first draft of my pseudocode. The algorithm here could have some specific purpose but entirely fail to achieve that purpose because of some mistake. How can we tell what was intentional from what wasn't?
Arglblarbl, this is driving me crazy!
http://hphotos-snc3.fbcdn.net/hs125.snc3/17256_810459615373_10240225_46642246_5176962_n.jpg
The original algorithm as found in my notebook. I have no recollection of when or why I wrote this. Note the little zig-zags at the bottom- those are visual representations of the way the different F functions advance j and k through the 2D array.
http://photos-d.ak.fbcdn.net/hphotos-ak-snc3/hs145.snc3/17256_810459839923_10240225_46642249_1708824_n.jpg
I transcribed it all onto the whiteboard in the CSEL. Hopefully someone will come by and instantly recognize the algorithm's purpose so I can stop going crazy.