From: Durant Schoon (durant@ilm.com)
Date: Tue Aug 14 2001 - 14:01:24 MDT
> From: "Ben Goertzel" <ben@webmind.com>
> Getting from pseudocode to program code is a matter of "procedural
> refinement", one aspect of procedural cognition -- and this can be very hard
> thinking, of course, involving invocation of relevant experiences, formal
> knowledge of algorithms, knowledge of the operating conditions of the
> program, etc...
Ah, this is nice! It sounds like that powerful term someone brought up
before: "intentional programming", where the intention (pseudocode) is
then brought to fruition (program code) by some process.
> In Webmind terms, the pseudocode level basically consists of a node-and-link
> representation of schema *without* any of the schema-specific bells and
> whistles (like token-passing to indicate that one procedure can't start
> until another has finished, etc.). The program code level consists of a
> fully-specified node-and-link representation of a schema.
>
> *IF* one had a procedural refinement approach that worked -- i.e. a set of
> mind-processes that take in pseudocode and spit out program code (in the WM
> case, the program code is a fully specified schema) -- then one would be
> well-positioned to tune the system to learn new pseudocode to approach new
> problems. Because for each new candidate bit of pseudocode, the system
> would know how to create a new program code embodying the ideas outlines in
> the pseudocode, thus being able to test the pragmatic validity of the
> pseudocode.
>
> If we're to use the human case as an analogy, then procedural refinement is
> going to have to be learned or minimally parameter-tuned by the system via
> experimentation in a simple action domain (simpler than the domain of
> modifying its own source code for example). Here is where all the classic
> AI problems of playing games, moving blocks around, etc., become potentially
> interesting. If a system can't translate pseudocode into program code in
> simple contexts like this, having it do so in the context of modifying its
> own behavioral schema is obviously pretty hopeless...
True. Though, to be general (not WM-ish here), goals need to be
translated to program code.
> The difference between these thoughts and our past WM work on schema
> learning is basically the strictness of the breakdown into two levels.
> Before we had
>
> --> SchemaConceptNodes, an abstract level for reasoning about procedures
> --> SchemaNodes, for actually carrying out procedures
>
> and we actually had relations between SCN's and SN's on different levels of
> granularity, but we hadn't formalized a distinction between two granularity
> levels of schema relationships (here posited as pseudocode-ish and
> program-code-ish)
>
> This is actually a point that was raised many times in past (WM-internal)
> discussions on schema learning, in the guise of the need for a "plan
> optimization" phase. But the idea there, I think, was that the first phase
> of schema learning would result in an inefficient but detailed program, to
> be refined into an efficient one. what I'm suggesting here is that the
> first phase actually doesn't result in the learning of a detailed program at
> all, but just a pseudocode sketch.
It might be important to state here *why* you want to distinguish
these two levels. I'd venture that if this is a good idea, it is good
because reasoning about pseudocode is easier than reasoning about
program code. Ok, now it's my turn to make an analogy:
Say we have two games SKETCH and DETAILED. The SKETCH board is a 16x16
grid and has ten pieces. DETAILED is a 1000x1000 board and has 300
pieces(*). Moves in SKETCH are equivalent to a number of moves in
DETAILED. It turns out that the DETAILED game can be played as moves
in SKETCH (SKETCH moves are translated to DETAILED moves). The mapping
is not 1 to 1, that is moves in SKETCH can be one of several sequences
of moves in DETAILED, the final game play, however, specifically score
is the same.
The game we want to play and win is DETAILED, but by playing SKETCH,
can we actually be better players at DETAILED. This analogy is
hopefully a useful and obvious one by now where:
SKETCH = pseudo code
DETAILED = program code
The simplistic, first thought is to conjecture that:
Learn to play SKETCH well and you can win at DETAILED.
This is our general guiding principle, but we all know that the devil
is in the details. Let's begin,
Some heuristics for writing good code(**) (These rules of thumb apply
both to SKETCH as well as to DETAILED):
GENERAL(***)
-------
* Reliability
If two moves satisfy the same goal all the time they are
equally reliable.
If one move satisfies a same goal more often than another
move, the first move is more reliable.
* Reuse / Modularity
Reusable, modular sets of moves are better.
Why? This lowers the number of techniques which have to be
remembered.
* Simplicity
Cognition on simpler moves is faster.
The above list can be used as guides for strategizing in both SKETCH
and DETAILED. Once a game plan has been found in SKETCH following
these heuristics, there may be several functionally equivalent
move-sets(*4) in DETAILED. The same heuristics can be applied when
choosing which move-sets to use in DETAILED.
We need to stop about here to undo a faulty, but thus-far useful,
assumption. We have not considered that in order to choose our moves
in SKETCH, we will sometimes need to acknowledge that strategy in
DETAILED does in fact need to influence our decisions in SKETCH.
I'm thinking of effieciency here. For example, when programming, we
can recognize that some low level data structures and techniques are
far more effiecient than others. When we diverge from our guiding
principle is when we have a set of moves that look good optimal
SKETCH, but there are actually better moves because some corresponding
moves in DETAILED will get us much farther.
So what we really need to know is:
How to play SKETCH well.
Know when playing SKETCH isn't enough and we need optimize in
DETAILED.
All of our learning algorithms come in handy when we have to balance
these two well. We want to spend most of our time in SKETCH, because
it's more effiecient. But we can't all the time, so we not only have
to have some way of switching to good moves in DETAILED, we need to
figure out a good way of know *when* to switch.
Lastly, it should be remembered, that there are always two goals major
being satisfied at all times:
1) Specific: to solve the problem at hand
2) General: to learn how to solve problems better later.
1) might use simple scoring techniques to choose one strategy over
another, but because of 2) complex knowlege relating to the why's
and how's of one strategy vs. another need to be analyzed and stored
for quick retrieval in the future.
Hey, I'm hungry. It's lunchtime in California...
----------
(*) The actual numbers do not matter.
(**) I'll freely intermix the coding example with the game play
analogy. A "move" can mean a series of "moves", ie. a series of steps
in a program or pseudocode.
(***)
FOR US HUMANS
-------------
* Familiarity (Recognizable Patterns for Multiprogrammer environments)
This just recognizes that a driving force in coding among
humans is the constraint that more than one human programmer
understand a section of code quickly and thoroughly.
Think recent trends emphasizing Patterns and eXtreme
Programming principles.
(*4) "move-sets" - Just a convenience term for a set of moves. It
might be one move, it might be many.
-- Durant Schoon
This archive was generated by hypermail 2.1.5 : Wed Jul 17 2013 - 04:00:37 MDT