3 ms·

Combinatorial function look up by example transformation, seriously slick in the 'how has no one thought of this before'[0] kind of way. [0]imo always a hallma

Combinatorial function look up by example transformation, seriously slick in the 'how has no one thought of this before'[0] kind of way. [0]imo always a hallmark of something special. Or maybe someone has thought of it and I'm out of the loop, but either way this approach seems seriously useful for streamlining the syntactic process of generalizing a function for a set of known inputs/outputs.

YeGoblynQueenne 6y ago
Sorry to burst your bubble, but that's basically Inductive Progamming in a nutshell :) https://en.wikipedia.org/wiki/Inductive_programming https://en.wikipedia.org/wiki/Inductive_programming The wikipedia article doesn't make it very clear but basically it's what you say. The paper accompanying the system in the article goes through a bit more detail on Program Synthesis, of which Inductive Programming is sometimes considered to be a sub-field, but in any case, Program Synthesis is generating programs from complete specifications while Inductive Programming is learning programs from incomplete specifications- i.e. input-output examples of the target program. Examples are often supplemented by constraints. The field goes back to the 1970's and is today comprised of two sub-fields, Inductive Functional Progamming, i.e. learning programs in functional languages and Inductive Logic Programming, i.e. learning programs in logic programming languages (and, incidentally, the subject of my PhD research). In particular, the way you describe TF-Coder reminded me of Algorithmic Debugging: https://en.wikipedia.org/wiki/Algorithmic_program_debugging https://en.wikipedia.org/wiki/Algorithmic_program_debugging In short, this was a technique first described in 1982 by Euhd Shapiro, that assisted a programmer with finding bugs in a logic program (in Prolog) by taking in examples of true and false statements that the program should prove or disprove, respectively, and identifying program statements that made a true statement unprovable, or a false statement provable. The funny thing is that, once you can do this sort of thing, identify which parts of a program lead to coverage of true and false statements, you can go the other way and also generate those statements. In any case, it's a huge field that goes way back and there are many pointers on more information in the wikipedia article.

YeGoblynQueenne 6y ago

Sorry to burst your bubble, but that's basically Inductive Progamming in a nutshell :) https://en.wikipedia.org/wiki/Inductive_programming https://en.wikipedia.org/wiki/Inductive_programming The wikipedia article doesn't make it very clear but basically it's what you say. The paper accompanying the system in the article goes through a bit more detail on Program Synthesis, of which Inductive Programming is sometimes considered to be a sub-field, but in any case, Program Synthesis is generating programs from complete specifications while Inductive Programming is learning programs from incomplete specifications- i.e. input-output examples of the target program. Examples are often supplemented by constraints. The field goes back to the 1970's and is today comprised of two sub-fields, Inductive Functional Progamming, i.e. learning programs in functional languages and Inductive Logic Programming, i.e. learning programs in logic programming languages (and, incidentally, the subject of my PhD research). In particular, the way you describe TF-Coder reminded me of Algorithmic Debugging: https://en.wikipedia.org/wiki/Algorithmic_program_debugging https://en.wikipedia.org/wiki/Algorithmic_program_debugging In short, this was a technique first described in 1982 by Euhd Shapiro, that assisted a programmer with finding bugs in a logic program (in Prolog) by taking in examples of true and false statements that the program should prove or disprove, respectively, and identifying program statements that made a true statement unprovable, or a false statement provable. The funny thing is that, once you can do this sort of thing, identify which parts of a program lead to coverage of true and false statements, you can go the other way and also generate those statements. In any case, it's a huge field that goes way back and there are many pointers on more information in the wikipedia article.