Steve, I still don't understand what you are getting at. Why does the ADI have to be in some sort of canonical form? What did you mean when you said it had to pass through a small set of functions?
You said: Further, I would expect the ALL data to have a similar set of characteristics regardless of its type - akin to the old value, significance, dimensionality; or meters, kilograms, seconds lists. Without semi-complete lists of block-functionality and data-characteristics, I don't see how design could usefully commence. Are you saying that all AGI projects have to be theoretically defined in order to begin to be designed? If that is what you mean then we are really not communicating. A traditional engineering project (like a bridge) has to be carefully planned. It would be very expensive, wasteful dangerous and absurd not to do it that way. However, this is a luxury of engineering that does not make as much sense in true research. So, to contrast, I could say that my fundamental design principles where, for example, plans not only can become the progenitor of other plans but must necessarily have that potential capacity, might be used as the basis for some pure experimentation. I could take that kind of thinking and use it in highly simplified experiments. Pure experimentation might not produce a true AGI program but my argument is that experimental forms of creative dynamic programming of relativist conceptualizations is exactly what is needed. So I wouldn't waste my time trying to design block functions and data-characteristics before I started designing my initial experiments. Of course I would have some sort of idea about the kind of data objects I had in mind but I don't see any real value in trying to express it in canonical form for example. Jim Bromer On Thu, Mar 19, 2015 at 3:28 PM, Steve Richfield via AGI <[email protected]> wrote: > Hi all, > > Some thoughts that might bring this together: > > 1. (Jim) APIs are for procedural environments, but it seems obvious (to > me) that an AGI definition under all (but a few narrow text-manipulation > concepts) would be structural, defining a diagram as PM posted. I coined > ADI to communicate that it defines a structure and NOT a procedural > function. Further, the data must ALL be in some sort of canonical form if > it is to all all pass through a small set of functions. > > 2. (Logan) SPEL is interesting, but it doesn't seem to be at any > particular meta-level, and in particular, doesn't seem to be particularly > suited to defining complex structures (as in PM's diagram) as future AGIs > would probably be. APL would be semantically better, but has serious syntax > issues. We need the best of both. > > 3. (PM) The fundamental things that intelligent creatures do - > recognizing and processing patterns, finding things that have down-stream > utility, etc., are largely independent of whether it is writing, speech, > vision, etc., that is being processed. Indeed, it is this very presumption > that has driven neural network R&D. Hence, I would expect a potentially > functional wiring diagram to specify which of a relatively small set of > prospective functions connect various sources and destinations of data. > Further, I would expect the ALL data to have a similar set of > characteristics regardless of its type - akin to the old value, > significance, dimensionality; or meters, kilograms, seconds lists. Without > semi-complete lists of block-functionality and data-characteristics, I > don't see how design could usefully commence. Here, either I am right in > making the above assertion, or someone should clearly make the point as to > how I am wrong, as this would/could/should drive all future AGI R&D. > > Steve > =================== > > On Thu, Mar 19, 2015 at 10:32 AM, 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/10443978-6f4c28ac> | >> Modify <https://www.listbox.com/member/?&;> Your Subscription >> <http://www.listbox.com> >> > > > > -- > Full employment can be had with the stoke of a pen. Simply institute a six > hour workday. That will easily create enough new jobs to bring back full > employment. > > *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
