Richard,
the instance nodes are such an
important mechanism that everything depends on the details of how they
are handled.
Correct.
So, to consider one or two of the details that you mention. You would
like there to be only a one-way connection between the generic node (do
you call this the pattern node?)
1) All nodes are equal.
2) Nodes can point to each other.
Yes, connection should be one way.
(E.g.: You know George Bush, but he doesn't know you :-))
Two-way connection can be easily implemented by two separate
connections.
For instance, we are able to see a field of patterns, of
different colors, and then when someone says the phrase the green
patterns we find that the set of green patterns jumps out at us from
the scene. It is as if we did indeed have links from the generic
concept [green pattern] to all the instances.
Yes, that's good way to store links:
All relevant nodes are connected.
Another question: what do we do in a situation where we see a field of
grass, and think about the concept [grass blade]?
Field or grass concept and grass blade concept are obviously
directly connected.
This link was formed, because we saw Field of grass and Grass
blade together many times.
Are there individual instances for each grass blade?
If you remember individual instances -- then yes.
Are all of these linked to the generic concept of [grass blade]?
Some grass blades may be directly connected to field of grass.
Other may be connected only through other grass blade instances.
It would depend on if it's useful for brain to keep these direct
associations.
What is different is that I see many, many possible ways to get these
new-node creation mechanisms to work (and ditto for other mechanisms
like the instance nodes, etc.) and I feel it is extremely problematic to
focus on just one mechanism and say that THIS is the one I will
implement because I think it feels like a good idea.
The reason I think this is a problem is that these mechanisms have
system-wide consequences (i.e. they give rise to global behaviors) that
are not necessarily obvious from the definition of the mechanism, so we
need to build a simulation to find out what those mechanisms *really* do
when they are put together and allowed to interact.
I agree -- testing is important.
In fact, it's extremely important.
Not only we need to test several models [of creating updating nodes
and links), but within single model we should try several settings
values (such as if node1 and node2 were activated together -- how
much should we increase the strength of the link between them).
That's why it's important to carefully design tests.
Such tests should work reasonably fast and be able to indicate how
good did system work.
What is good and what is not good -- has to be carefully defined.
Not trivial, but quite doable task.
I can show you a paper of mine in which I describe my framework in a
little more detail.
Isn't this pager public yet?
-
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/?member_id=8660244id_secret=73487197-bbb1fa
