From: bear@sonic.net   
      
   Mark Ng wrote:   
   >   
   > Don Geddis  writes:   
   >   
   > > 2. If you're trying to solve an "ordinary programming" problem, it takes   
   more   
   > >    effort describe the algorithm (in sufficient detail to get a work   
   solution)   
   > >    than it would be to just write it down in an "ordinary programming   
   > >    language".   
   >   
   > Can you give an example of that ?   
   >   
      
   I just wrote a parser for type 0 languages.  It is entirely sufficient,   
   from a "declaration" point of view, just to tell the system what each   
   reduction rule does to the expectation vector and under what   
   circumstances   
   it can use a shift rule.   
      
   But the result of doing that would be to have the system produce all   
   possible sentences, terminating when one were produced that matched the   
   input. The parser I wrote can do that, if you don't give it any parse   
   tables to work with, but that sucks, because it takes forever.   
      
   So I've put in parsing tables of inclusions and exclusions, and given   
   it the ability to derive "first" and "follow" sets so it can fill in   
   the parsing tables if the grammar is simple enough that such sets are   
   deterministically provable.  This speeds up the process immensely, at   
   the expense of increasing the amount of human thinking and specification   
   I have to do.  But that was very specific, procedural/theoretic   
   methodology there, a far cry from the "declarative" structure that   
   people would like to do.  And in general, it only works for languages   
   down to type 2; anything in type 1 or type 0, I still have to derive   
   the tables by hand because they're not generally provable.   
      
   So, I wind up giving this system "hints" about how to solve the problem   
   more efficiently, which amounts to a complexity approaching that of   
   procedural rather than declarative programming.   
      
   Now I'm trying to make it smarter; let it solve a few thousand problems   
   using the method that sucks, then look at the successful vs.   
   unsuccessful   
   parses and try to derive its own probabilistic parsing tables on   
   grammars   
   where deterministic ones didn't exist.  It's a nice AI/Learning project,   
   and will give me back the ability to just write grammars declaratively   
   in exchange for time spent "training" the system on example input.   
      
   But the bit that makes it smarter, once again, isn't declarative at   
   all:  deriving that information is very procedural, and requires close   
   attention to a lot of theory and a lot of fiddly bits -- in effect,   
   I'm giving the system a lot of specific , precisely formulated, high-   
   level know-how about parsing and analysis of input, and I'm doing it   
   the hard way, by explicit programming.  Once again, the nicely   
   "declarative" aspect of AI only comes from a bunch of sweat and code   
   in the explicit procedural style.   
      
   And the further back you push the procedural foundation, the more   
   specialized, abstract, and harder to specify and implement that   
   foundation becomes.   
      
   A "simplistic" parser needs only a test against input and an easy   
   transformation system to work on the expectation vector.  That's   
   too simplistic to be useful.   
      
   Adding the parsing tables, and the ability to derive mathematically-   
   provable tables from simple grammars gives it knowledge about the   
   grammar itself, and the ability to be directed by input.  That's   
   harder, but compiler writers do that all the time.   
      
   Adding the "training" feature so it can derive probabilistic tables   
   where mathematical proof is unavailable adds knowledge about parsing,   
   over and above knowledge of a particular grammar, and how to develop   
   methods of using particular grammars efficiently given particular   
   kinds of input.  But it takes us into space that is hard to code,   
   hard to express precisely, hard to understand, and full of   
   opportunities to get stuff wrong.   
      
   The next step -- making a system smart enough that it could have   
   derived the "learning" technique on its own -- would require insight,   
   technique, and resources I don't have.   
      
   And the step at the end of the journey -- a system with a   
   generalized ability to take a set of declarations about a task, and   
   constraints and actions and derive all by itself the most efficient   
   way to use those constraints and actions to solve that task --   
   requires insight, resources, and technique that, at this point,   
   nobody has.   
      
   				Bear   
      
   [ comp.ai is moderated.  To submit, just post and be patient, or if ]   
   [ that fails mail your article to , and ]   
   [ ask your news administrator to fix the problems with your system. ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)