I attempted to create a general purpose model for the exact version of the "what comes next problem." It enumerated primitive recursive functions, trying them out as it went. The limitation to primitive recursive functions was convenient because they always terminate. I didn't have to filter out the functions that ran for too long. (or do I?)
The enumeration inherently includes functions of several variables, so I wasn't restricted to examples such as 1->1, 2->4, 3->9, 4->16 etc.
I could try it out on examples such as (1,2)->3 (2,1)->3 (0,2)->2, etc. Perhaps with enough it would "learn to add" = find a primitive recursive function that did addition.
I got as far as finding the first problem. The enumeration technique that I used was effectively doing a tree recursion, like that function for computing Fibonacci numbers that bogs down because Fib(10) is computing Fib(5) lots of times. I had a lot of numbers that coded for the identity function, lots of numbers that coded for the first few functions, making the whole thing bog down, trying the same few functions over and over under different numerical disguises.
I thought that I could see my way to fixing this first problem. Have some way of recognizing numbers that give forms that give the same function. I guessed that I could approximate this by saying that if two functions give the same value on a variety of arguments they are probably the same. Then I parameterise this criterion and tune. That opens the way to creating a consolidated enumeration, analogous to fixing the tree recursive fibonacci function by memoization, except trickier.
But my health is poor and I ran out of energy.
Also, I have a guess for the second problem. What happens if I fix the first problem and my enumeration reaches decently complicated primitive recursive functions. While they will all terminate, some might run for far too long, causing the process to bog down. Rejecting them on the basis of limiting the run time might work well. We are happy to only learn reasonably effect functions for doing maths.
It is a fun idea and I encourage others to have a go.
The enumeration inherently includes functions of several variables, so I wasn't restricted to examples such as 1->1, 2->4, 3->9, 4->16 etc.
I could try it out on examples such as (1,2)->3 (2,1)->3 (0,2)->2, etc. Perhaps with enough it would "learn to add" = find a primitive recursive function that did addition.
I got as far as finding the first problem. The enumeration technique that I used was effectively doing a tree recursion, like that function for computing Fibonacci numbers that bogs down because Fib(10) is computing Fib(5) lots of times. I had a lot of numbers that coded for the identity function, lots of numbers that coded for the first few functions, making the whole thing bog down, trying the same few functions over and over under different numerical disguises.
I thought that I could see my way to fixing this first problem. Have some way of recognizing numbers that give forms that give the same function. I guessed that I could approximate this by saying that if two functions give the same value on a variety of arguments they are probably the same. Then I parameterise this criterion and tune. That opens the way to creating a consolidated enumeration, analogous to fixing the tree recursive fibonacci function by memoization, except trickier.
But my health is poor and I ran out of energy.
Also, I have a guess for the second problem. What happens if I fix the first problem and my enumeration reaches decently complicated primitive recursive functions. While they will all terminate, some might run for far too long, causing the process to bog down. Rejecting them on the basis of limiting the run time might work well. We are happy to only learn reasonably effect functions for doing maths.
It is a fun idea and I encourage others to have a go.