Hi, alex :)
> is this new idea what are your writing about ""intensional" > representation of deduction/abduction tree"? Do you have any literature or > references regarding this idea? I could be greate if You can share the > sources of your idea. I came onto this idea on my own (but maybe I'm just reinventing a wheel) and there is no literature known to me, that describes this kind of reasoning. Actually, things are not much complicated and so mystical below the surface of the problem. Let's consider a complex logic formula, consisted of operators for negation, implication, conjunction and disjunction. A structure of this logic formula forms a expression tree where each leaf has only one expression. Some of these expressions, when applied to logic axioms (and relevant other leafs), yield new formulas that can be placed as disjunctions with original leafs, in places of original leafs. It's a kind of equivalent to abstract syntax forest that comes as a result of parsing ambiguous data. One approach is to enumerate all of these leafs / trees in advance, before quering them for some purpose. The other approach is to have a "function" instead of each leaf / tree whose result *could be enumeration* of every leaf / tree that logically follows in the right places. *But, we don't enumerate these leafs / trees in advance*. Rather, we enumerate leafs / trees in a lazy way, only when checking whether a searched formula corresponds to certain leaf / tree in the whole forest. Knowing in advance what to search for in the forest, we can optimize the search process, rejecting paths that don't match with the formula we search for. This way, we can compare only fragments (say, beginning) of searched formula and check the rest of searched formula only if the previous fragments passed. Basically, algorithmic branching for checking remains the same, while the memory space for expressing each leaf / tree is not needed anymore, as we procedurally build a branch we want to check on demand, thus eliminating one of two important components responsible for combinatorial explosion, and that is *memory space usurpation*. The other component responsible for combinatorial explosion is *algorithmic branching complexity*, and it seems that this is going to be a hard nut to solve. Basis of it should be in converting recursive definitions (of, say, even numbers like "*f(x) -> (x, f(x + 2)), first x being 0*") to their non-recursive equivalents (like f(x) -> every x where x / 2 is integer and x >= 0). It turns out that this is not such a trivial task and I think that we are going to need an AGI to solve these kinds of questions on general level. I think, for now I'm going to settle down with the first part, meaning non-greedy-memory-approach, leaving algorithmic search space explosion solution for the future. Until then, my recommendation for users would be to avoid writing recursive definitions, noting them in non-recursive notation, where possible. Code generation is one of my goals but I have not implemented it yet. I > plan to do this in very crude way: I will have inference process whose > result will be abstract syntax tree (of some industrial programming > languages like Java, Typescript and HTML) as a Scheme code and then I will > generate actual code (Java, Typescript, HTML) from this syntax tree. My approach is to start from the bottom: to define an assembler. Then to give to user an opportunity to define higher level expressions that translate to assembler. Then an user can define even higher level expressions that translate to the level below. And so on with even higher levels, one of which may be the very natural language expressions... > Functional programming languages have no distinction between data and code > (at least I have heard about such thesis in Scheme book) - meaning - Scheme > data structures can be perceived as executable programs and that is why > generation of Scheme data structures can be the same as generation of > executable code (Javascript has some similar features) but I am not > pursuing this path because I want object-oriented code - the generated code > should be of industrial quality. Similarity between data and code is obvious for Lisp family of languages, but you could say that for any language around - as you can always express any code by an abstract syntax tree. What you do with that tree, execute it (treat it as code) or analyze it (treat it as data), it is up to you. I believe that object oriented approach of programming is just one side of the story: it is our current industrial reality. The other side is functional programming in a sense of lambda calculus. Some pretty mean possibilities open up in functional programming. You can think of inference process as a set of functions from assumptions to conclusions. In that sense, it would be a loss to overlook it and to concentrate just on OOP. I'm still not sure, but I think there is a special place for functional programming in the future. A place of scientific approach to solving problems. In AGI books (engineering AGI) there are chapters about evolutionary code > generation but the generated code is the result of genetic programming > process in that case. Genetic programming is quite relaxed and heuritic > method, I would prefere more rigorous automatic programming methods - code > should be generated in the inference process from the specifciation and > specification should be autoatically generated from the normas, best > practices, interaction with the customer. Of course, in this inference > process we can use adaptable, probabilistic, non-classical logics, but > nevertheless - logics should be used. Evolutionary search can not give > guarantees that inference process can give. Interactive successive problem specification could reduce a number of possible results, but if there are still many results in the process, a combination of genetic guessing and methodical inference could be a way to go. -- ivan 2017-05-09 20:08 GMT+02:00 Alex <[email protected]>: > Ivan, > > is this new idea what are your writing about ""intensional" > representation of deduction/abduction tree"? Do you have any literature or > references regarding this idea? I could be greate if You can share the > sources of your idea. > > Automatic programming is quite old field that has ceased to be develope in > nineties and after them there has been only development of templates. I am > not aware about big theories or sophisticated technologies behind model > driven development. > > Code generation is one of my goals but I have not implemented it yet. I > plan to do this in very crude way: I will have inference process whose > result will be abstract syntax tree (of some industrial programming > languages like Java, Typescript and HTML) as a Scheme code and then I will > generate actual code (Java, Typescript, HTML) from this syntax tree. > Functional programming languages have no distinction between data and code > (at least I have heard about such thesis in Scheme book) - meaning - Scheme > data structures can be perceived as executable programs and that is why > generation of Scheme data structures can be the same as generation of > executable code (Javascript has some similar features) but I am not > pursuing this path because I want object-oriented code - the generated code > should be of industrial quality. > > There is work in implementation of Goedel machine (self-improving > software) and as far as I have read about it, they are using lambda > calculus. > > In AGI books (engineering AGI) there are chapters about evolutionary code > generation but the generated code is the result of genetic programming > process in that case. Genetic programming is quite relaxed and heuritic > method, I would prefere more rigorous automatic programming methods - code > should be generated in the inference process from the specifciation and > specification should be autoatically generated from the normas, best > practices, interaction with the customer. Of course, in this inference > process we can use adaptable, probabilistic, non-classical logics, but > nevertheless - logics should be used. Evolutionary search can not give > guarantees that inference process can give. > > -- > You received this message because you are subscribed to the Google Groups > "opencog" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/opencog. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/opencog/2d3ac0f2-0d30-4d7f-9fce-25afc7be392f%40googlegroups.com > <https://groups.google.com/d/msgid/opencog/2d3ac0f2-0d30-4d7f-9fce-25afc7be392f%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "opencog" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/opencog. To view this discussion on the web visit https://groups.google.com/d/msgid/opencog/CAB5%3Dj6Vkok19un6iMHoU-QV4aTQgQX%3D5gG_80GwHYA4JF%2Bh4sQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
