Where the Yellow Brick road leads

"And Kansas, 'she said', is the name of the star".

The weather is brutal here today and I shoveled about 2.5 tons of the slushy frozen crap, myself. I didn't see many mosquitoes when I was out, it was nice to be away from those blood sucking vampires.

Backward induction says that as far as the puzzle goes, it can be considered a case where all elements have been selected except one. At this point, the problem is simple. You select one thing and put it in one place. This is as simple as a puzzle with one piece. So this is approached like the Fibonacci sequence computation, where we compute (element+element+1) recursively. I have covered this before and come to a method which simply swaps registers and adds in a loop. When `gcc` runs it does exactly the opposite of programming. In other words, I can take `gcc` and turn it inside out to generate any possible valid program by backward induction avoiding branch points that are errors. Now, that is the theory and "Many a plan of Mouse..." could be the outcome.

Ideas that came from 'open course ware' at MIT programming are really applicable here, or so it seems. I am also using information from Yale game theory. The problem of solving the puzzle and solving the program that solves the problem is the same issue. I start with the final case and move backwards. In this case I need to select an element from a list which is 1 in length and place it in an array which has one missing element. So the program that does this, requires a structure to keep an element and place that element in the array structure. Really it only requires a single variable "position" and a single "item" and returns a variable "position" with value "item" and so the position is 0 and item is 0 when using ZIL. The entire program is:

int solve(int solved_puzzle,int possible) {
return possible;
}

int main() {
int solved_puzzle=0;
int solution;
int possible=0;
solution=solve(solved_puzzle,possible);
return solution;
}

and the procedure above. I think this is the right approach to defining the process. By breaking it into parts and solving each part in sequence, the entire solution is exposed. I am sure this does not apply to all problems, but it is a good start and a good element to incorporate in the AI program generator. The program to create breaks out the same way with a tree of possible actions. At its lowest level, one could say we wish to represent the solution and so the program starts with a simple statement that "solution=only_possible;". The structure of where that is located can be seen in the program above and in any program there are elements and placement and it is very much like `gcc` inside out.

The levels of abstraction are solved puzzle or problem, up to program that solves the puzzle which has been debugged by an automated process, autodoc (exists) , autoconfig(exists), a program that creates make ,automake(exists) up to program which creates the program that solves the puzzle, up to the program that teaches programming, up to a program that acts intelligently to solve problems using programming and all the resources and information available. I am building all the levels of abstraction simultaneously and each stage creates the next stage until it is possible to define a problem or puzzle in a written form and end up with a program which solves it. By recursive development, at each stage I make the choices for a simple solution and increase the complexity of the problem. In this case, I start with a written puzzle that describes a puzzle which is an element and a single possible solution. I know that sounds like a given, but that is how it is done. Combine single instructions in a pattern that produces a result. I will post the n levels of abstraction and the programs that produce the solution.

So I start here. The description of the problem is that I have a puzzle that needs a solution from a set of possible items. From this I use the name 'puzzle' as input and 'solution' as output and items as a selector from the structure of the sentence. The values of possible, items, and puzzle are within the description and so the scope of variables can be determined from this data. If there were two solutions , then it would require an array. If the puzzle were two, it would also require an array. For the sake of consistency, all procedures are written the same way. Since it is created on the fly, I can define style within the constructor, and this way I can conform the final product to a standard. I need not consider style each time that I write code and others can regenerate the code in the form that is familiar or conforms to their spec. The description is first parsed to create name space options for the program and standard prefixes and post fixes. If it an array it can use set of prefixes that is appropriate. I will select my own. The process is done by program and in the upward process will be the output of another problem, completing the full circle.

I am taking it one step further to define what language is used itself. So I could make it produce javascript, C++, perl, python, shell, Regular Expressions, HTML, CSS, XHTML, or any other structured result based on the definition of how to take a definition of goal to a product which produces that goal in the format language selected along with the methods to compile and test the application. I will see how this works out in practice. I think there is enough information which can be collected to make the entire process coherent and self supporting and extensible.

<methods>
 <define (method)>
  <types(int,char,void)/>
  <option>
   define an integer variable before use
   int UNK;
  </option>
  <option>
   define a character variable before use
   char UNK;
  </option>
  <option>
   define a pointer variable before use
   void *UNK;
  </option>
 </define (method)>
</methods>