How are you going to input the problem to solve?
Good Question. This is how I would do it:
I would display an ascii graph of what a rubix cube would look like when unfolded. It would resemble a cross:
Code:
[ ][ ][ ]
[ ][ ][ ]
[ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ][ ][ ][ ][ ][ ][ ]
[ ][ ][ ]
[ ][ ][ ]
[ ][ ][ ]
[ ][ ][ ]
[ ][ ][ ]
[ ][ ][ ]
Next, I would prompt the user to then enter their current cube configuration. As long as the user is consistant, they can orient the cube as they desire.. and start entering their color scheme. This would be a good time to perform error checking. An easy way to do this.. would be a count of each color entered. IF a user enters 10 green squares for example, one could display an error, "green color count exceeded."
R = Red
B = Blue
W = White
O = Orange
Y = Yellow
G = Green
This is an example only and may not reflect a real life cube configuration:
Code:
[R][G][G]
[B][Y][W]
[Y][O][B]
[O][G][Y][R][W][W][O][G][Y]
[G][Y][O][W][B][B][R][G][G]
[B][B][G][W][Y][O][Y][O][O]
[R][G][R]
[B][O][R]
[O][O][W]
[G][R][Y]
[B][R [R]
[Y][O][O]
From this point, I run my algorithm for comming up with a solution to the rubix cube (which is to get all sides to be one solid color)
One algorithm I came up with right away.. would be to have the program run several different instances of randomly moving the cube.. keeping track of each movement.. until one of the random methods eventually achieves a solution. Keep a counter of moves for all the methods that achieve a solution.. and pick the one that has the fewest amount of moves. (This is the cheap, easy, inefficient way to do it)
Finally:
Tell the user to locate this face of the square (for example)
Code:
[R][B][W]
[O][Y][G]
[O][R][R]
Then I would run a solution function.. which would provide the user instruction to move thier cube.
example:
Code:
Move the top row of your cube 90 degrees clockwise so it will match this picture _
[Y][G][B]
[O][Y][G]
[O][R][R]
Repeat until the cube is solved:
Code:
[B][B][B]
[B][B][B]
[B][B][B]
The judging is going to be rather tricky...
Judging will be easier than you think. With a program of this caliber, it will be obvious when someone has come up with an efficient way to solve a cube. Scoring will be 'cut and dry' with no interpretation needed on my part. Your program must weigh the costs of reduced user input versus run time.. and amount of code.
since you should, to be fair, give the same input for each solution to see how each fairs under identical situations.
One criteria of the judging will be to see if you can take the minimum amount of user input in order to achieve a solution. In my previous examples, I promted for every single square. If a programmer can solve a cube if given.. let's say only 2 sides of a cube.. then that would score better than a program that prompts for all 6 sides the cube.
My ethics and scoring will be standard for all entrants.. which will make the contest as fair as possible. I have developed a standard checklist of criteria in which to judge each entry. The scoring for this aspect of the contest is simple. I am going to use a scale of 1 to 6. 1 being the user was prompted for "one side of the square".. and 6 being the user was prompted for "6 sides of the square."
Beyond this.. run time will be added to your score. Line length will be added to your score. Number of moves will be added to your score.
Person with the lowest overall score wins. (Kinda like a game of golf per se)
The overall goals of this contest are to mimic the goals of real life programming. A customer would want the fastest, most efficient, most accurate, program with the least amount of code... and with the least amount of input from the user.
elad: I would like a copy of that program please.. mail to here with a zipped attachment.