Steve, Thanks for explaining your point of view to me in a way I can understand it. What you are saying makes more sense to me now.
I still disagree (at least to some extent) because AGI has not reached the stage of development to where it has become (mostly) an engineering problem. So while these function interfaces (or structural definitions) can be designed to be reusable, I don't think that is a significant advantage at this time. I want to repeat some things I have said before to finish explaining my point of view. First of all I think we must be missing fundamental theory of computer science and that is a polynomial time solution to SAT. Secondly, I think that there is something about the way that we write programs which has been inhibiting our ability to create primitive AGI programs. These two problems combined (if they really are the problems) can explain the difficulty we have had to see much traction in AGI programming. So, for example, while I would use many of the standard contemporary techniques of writing functions, I am aware that the bottlenecks that we use to reduce the number of possible bugs in our programs may well be inhibiting us from seeing primitive AGI events in our programs. Why do I think this? Because if an ordinary program started creatively deriving its own conclusions about the data that is input to it it would be seen as a major bug. It is exactly the sort of thing that is *generally* a problem and it is exactly the sort of thing that has been *generally* eliminated by safe programming methods like eliminating as much globality as possible. Programming functions are designed with narrow parameter and result bottlenecks just because the programmers and hardware designers who came before us discovered that this was a great *general* way to reduce errors and simplify debugging. What are the harder bugs to find? Those that exist due to some unrecognized global variation. (Well when you have many bugs in your programming finding the individual bugs become more difficult but global bugs are usually the last to be discovered even in that context.) However, this could be something that might be alleviated by what you are talking about. If the programmer could define how actions might effect global structures those effects would be easier to watch when debugging (and it could be useful in further development of the program as well). But when you start talking about global effects in AGI I think you may be entering the frame problem. Jim Bromer On Thu, Mar 19, 2015 at 11:53 PM, Steve Richfield <[email protected] > wrote: > Jim, > > On Thu, Mar 19, 2015 at 8:21 PM, Jim Bromer via AGI <[email protected]> > wrote: > >> Steve, >> I still don't understand what you are getting at. Why does the ADI have >> to be in some sort of canonical form? >> > > Apparently many people working on AGI plan on writing separate code for > nearly every function, rather than implement general-purpose "function > boxes" that will do reasonable things to whatever data is presented to > them. I see this as a humanly impossible task, because THAT much code will > simply set up like so much concrete. > > Once you have bought into reusable general purpose function boxes, then > the data will have to be presented in some sort of standard form that the > function boxes expect. > > 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? >> > > I don't care if there are ad-hoc NNs doing the work, or matrix-implemented > ML doing the work, or just lots of ad hoc code. My point is that to avoid > writing new code for every function, there MUST be standardization of data. > > Yes, different data represents different things. Some represents physical > position, some represents sensor magnitude, some represents probabilities, > etc., so obviously, functions must work on the sorts of data they were > designed to work on. However, beyond that, data of the same sort should be > processable by any function that is capable of handling data of that sort. > > 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. >> > > Still, dimensionality IS important even for experiments. Adding forces or > separations makes sense, but adding probabilities (without then subtracting > their product) does NOT make sense. Experimenting on things that make no > sense would be a waste of time. If nothing else, typing the data would > serve as a validation that a particular function was reasonable to perform. > > 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. >> > > Go ahead and experiment, but don't then expect to salvage your code in a > later AGI implementation. > > >> 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. >> > > If you are the only programmer, don't share code, plan to write very > repetitive code, etc., then go ahead and do things without standardization. > > Steve > ========== > > 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> >> <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 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
