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 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
