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 | Modify Your Subscription AGI | Archives | Modify Your Subscription AGI | Archives | Modify Your Subscription AGI | Archives | Modify Your Subscription ------------------------------------------- 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
