Let’s rewrite this in something C-like:
int a // a = 0 int b // b = 0 int c // c = 0 a++ // a = 1 a++ // a = 2 b = a * a // b = 4 c = a << a // c = 8 c = b * c // c = 32 c = c + a // c = 34 b = b >> a // b = 1 c << b // c = 1156 c++ // c = 1157 c = c * a // c = 2314
13 lines.
1 int a //a=0 2 int b //b=0 3 inc a //a=1 4 inc a //a=2 5 shl a,a //a=8 6 b=a*a //b=64 7 inc a //a=9 8 b=b+b //b=128 9 b=b+a //b=137 10 a=a*b //a=1233 11 a=a*b //a=168921 12 inc a //a=168922 13 a=b*a //a=23142314
Yep. Effectively you’re just writing code in a very restricted subset of assembly language.
A more interesting exercise would be to write a program which would output such code with certain (I suspect, limited) guarantees of optimality .
Say a number (below 1 billion), I’ll give you (optimal) code.
You had a genetic algorithm at some point—is that what you are using?
I wouldn’t call it genetic. But yes, I have an algorithm to solve this kind of problems.
13 lines are also just enough for 23142314.
Let’s rewrite this in something C-like:
13 lines.
Yep. Effectively you’re just writing code in a very restricted subset of assembly language.
A more interesting exercise would be to write a program which would output such code with certain (I suspect, limited) guarantees of optimality .
Say a number (below 1 billion), I’ll give you (optimal) code.
You had a genetic algorithm at some point—is that what you are using?
I wouldn’t call it genetic. But yes, I have an algorithm to solve this kind of problems.
13 lines are also just enough for 23142314.