The word 'plan' is ok, but the source of the word is old AI. I took a free online course on AI Planning and I really enjoyed it but it was clear that they were talking about traditional AI methods. While you might be talking about something that transcends traditional AI, you haven't actually acknowledged it or been able to say anything that would indicate that you understand what I am talking about. Your response seemed ambiguous and vague (relative to what I am saying).
I am spending a lot of my time working on logic. But, I have taken a great deal of time explaining that I would use logic in a coherent (a coherentist model). Furthermore I recognize that this model would also be relativistic. So I have made it very clear that I am thinking about using logic in a non-traditional way. I can do the same to make it clear that I get what you were saying. There is a difference between the code and the plans that the program might create. The word 'plan' is ok with me. I assume that you are saying that the sort of thing that I was calling a process would be better called a plan. But the word plan in the traditional model of AI Planning referred to a construction of a context-free plan. (Context-Free means that while each step may be part of a greater context, and even use something from the context as a parameter, the execution of the step is unambiguous. Even if there is some degree of uncertainty in a step of a plan the whole idea in the traditional model is that this uncertainty can be resolved through some process. (The process might include further learning.) But the obvious truth is that uncertainty and the unknown cannot always be resolved but the AGI program still has to be able to integrate separate pieces of related knowledge so that it can make reasonably good decisions about familiar events even if there are numerous differences between the present event and events that it dealt with in the past. In human kind, you have people who formally declare that they have a strong opinion about some subject or how they deal with some issue but when they have to make practical adjustments they react differently even though it seems like they are unable to comprehend the contradiction in what they say and what they do (in those certain circumstances.) For instance. Not only can I create plans but I can also create a plan to determine the criteria for creating plans. Once I have gained experienced doing this in relatively narrow circumstances, I could then start to generalize this method of determining when to create new plans and how to shape them. This general method does not have to be something that someone else (like a programmer) determined for me, it can be something that I made up for my own reasons and for my own purposes. Jim Bromer On Thu, Mar 19, 2015 at 1:32 PM, Piaget Modeler via AGI <[email protected]> wrote: > A small change in your thinking may have a tremendous impact. Why don't > you substitute the word "plan" for "procedure", and "concept" for "data"? > > Procedures are linked to code which is programmed by a programmer. This > term creates a sort of functional fixedness that can limit one's thinking. > > But a "plan" is general, and vague, even vacuous. A plan must be > interpreted and can have a string representation, but that representation > is not > source code. It's something else. > > Why not talk about creating "concepts" and "plans" instead of "data" and > "procedures"? Then you can have a concept object and > a plan object with methods and attributes. Let me try a simple > substitution for you: > > *"This may be one of the most important differences between our points of > view. Of course there is going to be an underlying program and the > 'processes' that the program will create as it is running will be different > from the underlying program. But, I believe that the programmer needs to > fully accept that an AGI program needs to be able to create and even learn > about plans. These plans may relate to the concept objects of the > environment (robots, for example, have to learn to develop plans for doing > things in the real world), but the plans will need to be related to > the programming world as well.* > > *"All AGI programs are going to need to develop some kind of plans to deal > with concepts that they define and learn about. It is my belief that the > programmer has to accept this fully and explore the implications of such > things if he genuinely is reaching for true AGI. (I am not trying to work > on a full AGI program but I am saying that the first step I need to take is > to go beyond the conventional notions that interfere with a more mature > understanding of the situation.) So a lot of people say that they (or some > agi researcher) are talking about the same thing I am talking about but on > those rare occasions when they try to show me some evidence of this I am > always somewhat surprised when the evidence that they find doesn't seem to > support the claim that they are talking about the same thing I am.* > > *"The simplicity of my view point is obscured by the fact that the > discussion of what constitutes concepts and what constitutes plans is > relative. In fact, one of the things that I have mentioned is that since a > plan may be stored as concepts, and we can talk about it - or use it- as if > it were some kind of object, this shows that the relativism of the nature > of these distinctions can be extremely subtle. However, again, my point is > that I am trying to say that the programmer has to fully understand the > nature of the thing if he is going to try to reach for AGI. He has to > understand that objects are not only relative but relativistic and then see > if he can take that idea and work with it.* > > > Does that scan well? Does it help to know that your program is > manipulating plans and concepts--even forming a conceptual ontology, and > invoking plans, rather than just data and procedures. In fact it is the > underlying procedures you write in a typical programming language which are > manipulating these concepts and plans. > > Your thoughts? > > ~PM > > ------------------------------ > Date: Thu, 19 Mar 2015 12:36:26 -0400 > > Subject: Re: [agi] AGI Application Definition Interfaces > From: [email protected] > To: [email protected] > > On Thu, Mar 19, 2015 at 12:46 AM, Piaget Modeler via AGI <[email protected]> > wrote: > > Jim, > I think you have to differentiate what the data of your AGI program is > from what the processes are. That is the first step. > Define some abstract processes and define what data they need in order to > operate. > I think the essence is having good knowledge representation(s). > ~PM > > > This may be one of the most important differences between our points of > view. Of course there is going to be an underlying program and the > 'processes' that the program will create as it is running will be different > from the underlying program. But, I believe that the programmer needs to > fully accept that an AGI program needs to be able to create and even learn > about procedures. These procedures may relate to the data objects of the > environment (robots, for example, have to learn to develop procedures for > doing things in the real world), but the procedures will need to be related > to the programming world as well. > > All AGI programs are going to need to develop some kind of procedures to > deal with data that they define and learn about. It is my belief that the > programmer has to accept this fully and explore the implications of such > things if he genuinely is reaching for true AGI. (I am not trying to work > on a full AGI program but I am saying that the first step I need to take is > to go beyond the conventional notions that interfere with a more mature > understanding of the situation.) So a lot of people say that they (or some > agi researcher) are talking about the same thing I am talking about but on > those rare occasions when they try to show me some evidence of this I am > always somewhat surprised when the evidence that they find doesn't seem to > support the claim that they are talking about the same thing I am. > > The simplicity of my view point is obscured by the fact that the > discussion of what constitutes data and what constitutes procedure is > relative. In fact, one of the things that I have mentioned is that since a > procedure may be stored as data, and we can talk about it - or use it- as > if it were some kind of object, this shows that the relativism of the > nature of these distinctions can be extremely subtle. However, again, my > point is that I am trying to say that the programmer has to fully > understand the nature of the thing if he is going to try to reach for AGI. > He has to understand that concepts are not only relative but relativistic > and then see if he can take that idea and work with it. > Jim Bromer > > On Thu, Mar 19, 2015 at 12:46 AM, Piaget Modeler via AGI <[email protected]> > wrote: > > Jim, > > I think you have to differentiate what the data of your AGI program is > from what the processes are. That is the first step. > Define some abstract processes and define what data they need in order to > operate. > > I think the essence is having good knowledge representation(s). > > ~PM > > ------------------------------ > Date: Thu, 19 Mar 2015 00:00:20 -0400 > Subject: Re: [agi] AGI Application Definition Interfaces > From: [email protected] > To: [email protected] > > I am still not getting it. What does ADI stand for? > Most of the ideas that I talk about are not expressed in terms of > actual pseudo-code even though some of them might be. I really don't know > how an AGI program would all be put together because I see significant > definitions as being acquired and learned. (In other words, not only does > an AGI program need to be able to learn but it also has to be able to > acquire new abstractions, formalizations and programming as well.) That is > so significant that I am not really sure how the underlying program would > work. My program would rely on a lot of trial and error concept fitting for > example. (Or it would be using a lot of trial and error to fit data > objects that are concept-like in some ways.) While this is something that > could be expressed at a high level block code, I really cannot see how the > details would work in an actual design because I don't know what kind of > problems will occur. > Here is another example of the problem. I mentioned that some very > reasonable methodical approaches to analyzing field data of imagery led to > np problems. When Matt challenged me to give an example of how a polynomial > time solution to Boolean SAT would solve image analysis problems I was > stuck because I realized that while many methodical approaches to field > analysis led to exponential explosions of complexity, I wasn't sure how > they could be solved by SAT solutions in p because I hadn't gotten far > enough to explore that kind of resolution to the problem. I need p=np to > develop useful solutions so I have not been very motivated to look for SAT > solutions to image analysis. > > Jim Bromer > > On Sun, Mar 15, 2015 at 11:23 AM, Steve Richfield via AGI <[email protected] > > wrote: > > APIs have a problem in AGI - they tend to be procedural. Down in the > bowels of a future AGI program there will doubtless be plenty of procedural > code, but at the higher levels "programming" will be more defining how > (virtual) things are put together - more like describing a block wiring > diagram than code. So, to avoid misleading acronyms, let's talk about ADIs > instead of APIs. > > Further, let's try and separate ourselves from whether these are > subroutine calls to set things up in tables, commands to an interpreter, or > fodder for some futuristic compiler. We should be MUCH more concerned with > the semantics of this, than with its syntax. > > As I recall from long ago, there was a language that was created to define > complex wiring diagrams at the block level - APL, which was created by Gene > Amdahl to facilitate the design of the IBM-360 line of computers. APL fell > into disfavor because it used strange symbols, though many/most APL > programmers used macros to give the obscure symbols convenient English > names so they could avoid writing in Sanskrit. > > After the 360, APL enjoyed considerable use among those doing financial > modeling (a LOT like AGI, only with smarter "neurons"), but was eventually > superseded by various proprietary languages. > > DOES ANYONE HERE SPEAK APL WELL ENOUGH TO DISCUSS ITS POSSIBLE ADAPTATION > FOR AGI? > > Language aside, I wonder what goes on at the block level inside of Ben's > code? I suspect it is a bunch of blocks - some (like early visual layers) > being completely predefined, and other blocks being neural networks or > something related. There is (probably) a hand-coded control structure of > some sort. > > I would think we should start with what people like Ben are already doing, > and generalize from that to be able to define interconnected blocks with > enough variability to be able to BOTH do what present experimental code is > doing AND what systems of biological neurons are suspected of doing. > > Once we have isolated the functionality of the individual blocks from the > structure that tells them how to organize and how to interconnect, it will > become possible for AGI coding to be fully reusable in a world that > implements smarter blocks and smarter definitional systems. > > BEN AND OTHERS WRITING EXPERIMENTAL AGI CODE: HOW DO YOU DESCRIBE THE > STRUCTURE OF YOUR SYSTEMS? > > The above aside, I wonder what ELSE we should look at to further define > this conversation? > > Thoughts? > > Steve > > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/24379807-653794b5> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > > > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/19999924-4a978ccc> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/24379807-653794b5> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > > > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/19999924-4a978ccc> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > *AGI* | Archives <https://www.listbox.com/member/archive/303/=now> > <https://www.listbox.com/member/archive/rss/303/24379807-653794b5> | > Modify > <https://www.listbox.com/member/?&;> > Your Subscription <http://www.listbox.com> > ------------------------------------------- AGI Archives: https://www.listbox.com/member/archive/303/=now RSS Feed: https://www.listbox.com/member/archive/rss/303/21088071-f452e424 Modify Your Subscription: https://www.listbox.com/member/?member_id=21088071&id_secret=21088071-58d57657 Powered by Listbox: http://www.listbox.com
