Steve Richfield <[email protected]> wrote: > Whoever succeeds in AGI will succeed because they deviated > from the group, rather than because they agreed with the group. This group > is **GREAT** at pointing out the holes in things, and thereby saving you > from wasting years of your life chasing rainbows. However, don't look to the > people here (including me) for guidance as to what IS the correct way to > build AGIs.
Let's suppose that a polynomial time solution to SAT is found. Does that mean that AGI is solved? Of course not. But it does mean that programmers can get more traction with abstractions that are vital to AGI using AI that is a little *more artificial*. The result is that all sorts of ideas that were out of reach can suddenly be tested. Furthermore, new methods of organization can be derived from the methods that need to be developed for an advance like this. These new ideas are like new technologies that can then be applied to AGI. At that point your ADI might be extremely useful, but, if they are premised on the idea that new insights about SAT are from the chasing rainbows paradigm then it is much less likely that your ADI would be adaptable to the innovation. That's the problem with the expectations of incremental science. If you are working in an engineering field then there is no problem basing your work on incremental science. But, if there is any reason to believe that the technology that you are trying to create needs some revolutionary advances then the dependence on incremental science is much more likely to fail simply because it cannot anticipate how the advances could shape your project. The whole point is that you can't predict where the advance will come from. I am saying that polynomial time SAT is a good candidate for advancement because it feels right and the poof that it is impossible isn't real. But I can't say for sure so I am not going to design an elaborate AGI project around the premise that it is. Jim Bromer On Mon, Mar 23, 2015 at 12:44 PM, Steve Richfield <[email protected]> wrote: > Jim, > > On Mon, Mar 23, 2015 at 6:52 AM, Jim Bromer via AGI <[email protected]> wrote: >> >> Steve: >> There is a difference between an engineering project, where the >> fundamentals are all well known and there is a broad consensus between >> experts and a true research project where there is not much agreement >> even amongst experts. > > > Once you start writing code for anything as complex as AGI, it **IS** an > "engineering" project, even though you can't presently see where that > engineering is going. > >> >> There is a innovation in bridge building, for >> example, but that innovation is forged from well tested and carefully >> studied scientific or technological applications from other fields. > > > AGI is NEVER EVER going to work until it is first understood about as well. > You can't replace 150 millions years of evolution with a few months of > unguided code twiddling. >> >> >> One mistake that I have made is that I believed that by discussing >> this for years in a group like this I will be better prepared to get >> my project going. The problem is, that I keep getting sidetracked in a >> lot of side issues that I just don't agree with. > > > Here we agree. Whoever succeeds in AGI will succeed because they deviated > from the group, rather than because they agreed with the group. This group > is **GREAT** at pointing out the holes in things, and thereby saving you > from wasting years of your life chasing rainbows. However, don't look to the > people here (including me) for guidance as to what IS the correct way to > build AGIs. > >> However, as I have >> said, I did realize after discussing this with you that I really need >> to further develop different theories about how my (different) ideas >> might be transferred from one IO modality to another (if some of them >> worked). So I appreciate that aspect of this thread. As I said, this >> idea is great for a rough sketch of a plan but it won't make the >> needed innovations and discoveries for you. > > > Here again we agree. I saw my proposal for canonical forms and interfaces as > a sort of "blackboard" on which to test new ideas, to avoid having to write > large amounts of code to test new theories. > > Steve > ========================== >> >> On Mon, Mar 23, 2015 at 2:31 AM, Steve Richfield >> <[email protected]> wrote: >> > Jim, >> > >> > On Sun, Mar 22, 2015 at 7:03 PM, Jim Bromer via AGI <[email protected]> >> > wrote: >> >> >> >> <snip> >> >> 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. >> > >> > >> > These are the words of someone who lacks experience designing >> > large-scale >> > systems. It only takes around twice the work of writing a single >> > interface >> > to write a general interface. Often in the final analysis the payoff >> > comes >> > in the first interface, because this exercise forces you to consider >> > EVERYTHING at the beginning, rather than having to revisit the interface >> > for >> > everything you forgot to put into it when you first created it in haste. >> > >> > Of course, if you are going to exchange code with someone else, the >> > payoff >> > is immediate. >> > >> > It is my guess that early attention to details that are easily put off, >> > like >> > adjusting operation (learning), will force drilling down into the REAL >> > (but >> > hidden) nuts and bolts of AGI - the very things for which you have been >> > searching. >> > >> > Ignoring canonical forms and standard interfaces may be sentencing you >> > to a >> > lifetime of fruitless search. >> > >> > Steve >> >> >> ------------------------------------------- >> AGI >> Archives: https://www.listbox.com/member/archive/303/=now >> RSS Feed: https://www.listbox.com/member/archive/rss/303/10443978-6f4c28ac >> Modify Your Subscription: >> https://www.listbox.com/member/?&; >> Powered by Listbox: 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
