On 3/12/07, Russell Wallace <[EMAIL PROTECTED]> wrote:
"Represented in logic" can mean a number of different things, just
checking to see if everyone's talking about the same thing.
Consider, say, a 5 megapixel image. A common programming language
representation would be something like:
struct point {float red, green, blue;};
point *image = new point[n];
For AGI purposes if that's our only representation well obviously we lose.
So we do need to take at least some steps in the direction of a unified
representation.
What should that representation look like? The answer is that logic, or
some variant thereof, is as good as we're going to get. So we might have
something like:
[Meaning #1]
color(point(1, 2), red) = 3
...another 14999999 similar assertions
Now we can build up further layers of information, such as:
[Meaning #2]
edge(point(4, 5), orientation(3.7))
estimated-depth(point(87, 9), 120.4)
convex(line#17)
chair(object#33)
...etc
What about the algorithms that generate those further layers of
information? Well, typical image processing code is written in something
like C, but again for AGI purposes if we do that we lose. So,
[Meaning #3]
we want to create (whether by hand, auto learning or most likely
combination) algorithms in a more logic-oriented language, something that
(at least superficially) looks more like Prolog or Haskell than C.
A classic mistake is to slide a step further and assume
[Meaning #4]
the application of those algorithms will be pure deduction and the runtime
engine can be purely a theorem prover. We now know that doesn't work, at
best you just run into exponential search, need procedural/heuristic
components. So leave that aside.
What about the physical representation of all this? Well suppose the
general logic database stores stuff as a set of explicit sentences, then
[Meaning #5]
we can use the same database to store all kinds of data as explicit
sentences. Do we want to? For prototyping, sure. For production code, we'll
eventually want to do things like _physically_ storing image data as an
array of floats because there's a couple orders of magnitude performance
improvement to be had that way - only a constant factor to be sure, but
enough to be eventually worth having. But that has no bearing on the
_logical_ side of things - the semantics should still be just as if
everything was stored as explicit sentences using the general database
engine.
So the answer to whether standardizing on logical representation is good
is:
Meanings #1, 2, 3 - yes.
Meaning #4 - no.
Meaning #5 - for prototyping sure, not for production code.
Hi Russell,
Thanks for clarifying all this.
I agree with the above analysis, ie Meanings 1,2,3, and 5. In addition,
1. re #4: As an example, the logical term "chair" is defined, as a logical
rule, by other logical terms like "edges", "planes", "blocks", etc. Sensory
perception is a process of *applying* such rules; algorithmically this is
known as *pattern matching*: we're given a set of low-level features (edges
etc) and we need to search for (match) the description of a chair. The
computational bottleneck here is that there can be a huge number of
objects-to-be-recognized, such as chair, table, car, human,... a gadzillion
things. This classic problem is *already* addressed by the rete algorithm.
2. At the very lowest level (from pixels to edge detection, blob detection,
etc) I think we must use neural-like, specialized algorithms. Using a
logical representation is not practical here. But we lose nothing, because
this level is sub-conscious, like the retina is to the brain.
YKY
-----
This list is sponsored by AGIRI: http://www.agiri.org/email
To unsubscribe or change your options, please go to:
http://v2.listbox.com/member/?list_id=303
