I think Logan misunderstood me. Of course I think plans are important. (How could I explain all my postings to groups like these for all these years.) And I think that Steve's idea about an application definition interface was ok - up to a point. In fact, he made me think of something that I have never really tried to answer in the nearly 20 years I have been writing in groups like this.
However, when he starts talking about project he wants us to join in even though he has not actually started by providing us with any of his own definitions - and he wants these definitions in canonical form - I have to draw the line. That's not how it is done. It doesn't work that way. You write interface definitions when you have so many interfaces that no one can recognize them by name. You need some kind of abbreviated record keeping. And canonical form is either for some high art or for some widely used system. People who start with high formal definitions about nothing that exists in any kind of application (mathematical rules or programmed code) don't usually get very far. Especially when it is supposed to be an application definition. So of course I have plans. I 'talk' about them all of the time in this group. I have always thought that if my ideas worked in one limited AGI form then I could generalize them to other IO modalities as I wanted. However, when I thought about what Steve was saying when he talked about defining the application interfaces for different kinds of data types I started to realize that I had never taken that next step very far and worked out how some idea that I was thinking of using in a text-based (limited) AGI program might be applied to work with visual data. I have thought about it but I never wrote anything down. So while I think Steve's idea was too exaggerated, I did think that the more simple stages of imagining how this might work with different kinds of data fields - and writing it down - would be a good idea. Of course I have plans but I know enough to know that I am going to need to learn a lot from experimentation if I ever hope to make some practical advances in AGI. Jim Bromer On Sun, Mar 22, 2015 at 10:03 AM, Logan Streondj <[email protected]> wrote: > Jim, > > I guess what I'm trying to say is, > if you are in a desert, with no plan of what to do or where to go, > then you are likely to just wander in circles. > > If you're trying to make water out of sand (SAT solving), > you may never accomplish anything worthwhile. > > Others have a plan and are growing a plant (project), > or even establishing an oasis (OpenCog eco-system), > > You did do some work on data storage and retrieval, don't know if you > mentioned it here, but so far that sounds the most useful thing you've > accomplished. > > That's probably the best way, solving concrete small problems, and > working your way up to bigger ones. > > So far you have the roots of the plant (data storage), > perhaps it can sprout some leaves. > > we all wish to transform the desert into a place more full of life. > > > Logan ni nya ya > > > On Sat, Mar 21, 2015 at 09:27:49PM -0400, Jim Bromer via AGI wrote: >> Logan Streondj via AGI <[email protected]> wrote: >> > sounds like Jim may have issues with commitment, >> > as in committing to a particular idea long enough to express it, >> > define it, write it, test it, debug it, and then make a better >> > prototype. >> >> I have been spending a lot of time on SAT again so I haven't done much >> programming unfortunately. I think that the prototypes have to be >> developed before canonical forms can be designed. However, I was >> thinking the other day and I realized that if a major advancement >> (like something in SAT) was found then all sorts of ideas could be >> reexamined and it wouldn't be surprising if many of them were capable >> of achieving some sort of primitive level AGI. So canonical forms of >> ADIs might make more sense. That is, if you think it is reasonable to >> expect that an unexpected major advancement in computer science (like >> a polynomial time SAT solver) will occur in the near future then an >> ADI like the one Steve has in mind is perfectly reasonable. If not >> then you have to assume that better AGI programs are going to require >> so much trial and error development then it is unreasonable to assume >> that spending a lot of time on the design of canonical interfaces is >> going to get you very far. >> >> I spent a lot of time creating a very basic data storage and retrieval >> system for my would be AGI project. It absorbed a huge amount of time >> and effort and while the design is probably adequate it added to the >> complexity of the preliminary design. I am almost to the point now >> that I might achieve more if I started with an elementary data storage >> and retrieval system and just did some primitive experiments with the >> ideas that I have been talking about. Then if I get something >> interesting I can begin to add elements from the more advanced storage >> and retrieval system I have already created. >> >> Since my SAT project has not gotten off the ground that plan is >> looking a little more likely. But the point is that the elaborate >> preliminary planning does not really make all that much sense for a >> truly experimental project unless it was specifically aimed at >> creating the appropriate tools for the experiments. >> Jim Bromer >> >> >> On Sat, Mar 21, 2015 at 3:25 AM, Logan Streondj via AGI <[email protected]> >> wrote: >> > On Thu, Mar 19, 2015 at 08:53:44PM -0700, Steve Richfield via AGI 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. >> > >> > the reusable function boxes sounds like flow based programming >> > and hardware programming in general. SPEL will definitely support it, >> > as perhaps the main paradigm. As I see it only way to improve upon >> > the performance of vanilla C/C++ is by going with OpenCl and HDL's. >> > >> > >> >> > >> >> > >> >> > 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. >> > >> > Yep, SPEL is a standard that is both human and machine compatible. >> > >> >> > 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. >> > >> > sounds like Jim may have issues with commitment, >> > as in committing to a particular idea long enough to express it, >> > define it, write it, test it, debug it, and then make a better >> > protoype. >> > >> >> >> >> Steve >> >> ========== >> > >> > Logan ni nya ya >> > >> > >> > ------------------------------------------- >> > AGI >> > Archives: https://www.listbox.com/member/archive/303/=now >> > RSS Feed: https://www.listbox.com/member/archive/rss/303/24379807-653794b5 >> > Modify Your Subscription: https://www.listbox.com/member/?&; >> > Powered by Listbox: http://www.listbox.com >> >> >> ------------------------------------------- >> AGI >> Archives: https://www.listbox.com/member/archive/303/=now >> RSS Feed: https://www.listbox.com/member/archive/rss/303/5037279-a88c7a6d >> Modify Your Subscription: https://www.listbox.com/member/?&; >> Powered by Listbox: 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
