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
