Re: What did that thread indicate?

Traveler <traveler@xxxxxxxxxx> wrote:
> On 27 Sep 2005 21:12:33 GMT, curt@xxxxxxxx (Curt Welch) wrote:

> >You keep telling me to stop saying "my net does that" but yet, you keep
> >saying my net is missing important features which in fact are
> >fundimential to its design. How can I help but keep saying "my net does
> >that"?
>
> You cannot have a single homogeneous net that does so many things at
> once. Besides, some of these things must be done in stages. IOW, you
> must start with signal separation (one principle) and then do signal
> fusion (another principle). Only then can you do sequence formation
> and motor control. You cannot do these things in the same network. You
> must have multiple subnetworks feeding signals to one another. On top
> of that, you must do concept formation, conflict detection, motor
> coordination, reinforement learning, etc... There is a reason that the
> brain has multiple integrated cell assemblies each with its own
> function and principle. In the brain, bi-directional signal pathways
> between subnetworks are the norm, not the exception.
>
> You come out sounding like the nodes in your net can do all these
> things simultaneously. This is complete crap, Curt. You're dreaming
> and you're only fooling yourself.

Of corse I'm dreaming. So are you. As John said, it might all be fools
gold which I'm dreaming about. I don't deny that.

But, the output of every node in my network is doing signal separation.

Signal fusion is happening at the input to each node when two separate
signals are routed together.

A few years back, I was working with the idea of a system with two
networks, which I called the inet and onet. In that approach, my inet was
doing signal seperation, and the onet was doing signal fusion. But I've
since figured out that was not the right answer. Instead of doing those
important functions at the network level, it's better to do them at the
node level - which is why each node now does both fusion and separation.
So what you say "must" be done at the network level, I've built into the
node level. This allows my network to separate, and fuse, signals together
many times, in many different way, with one pass through the net. Doing it
this way is required in order to solve the curse of dimensionality in my
opinion. Otherwise, the number of separate signals that come out of the
separation network would grow exponentially with the number of inputs.
When you separate and fuse repeatedly at the node level, the dataset size
(network width) doesn't need to grow expontionaly.

I believe sequence formation will be best done by global feedback on my
type of network. But this is not something I've experimented with yet.

What you seem to call motor control I see normally as IO processing outside
the scope of general AI. It's nothing more than an signal adapter problem
to map the signal format used in my network, to other formats to match the
need of external systems. To learn to drive a car (or operate any tool),
the general AI engine must have enough learning power to deal with any
external control system. So if we get the core system correct, then you
should be able to attach ANY external addater to the outputs and the core
system will learn what is needed to use that adapter to control some
external device. The exernal adaptor will simply look like more of the
external environment which the core system will be required to deal with.

And of course you know I believe reinforcement learning is important. But
instead of putting it in yet another network, I'm also building that into
every node. So what you seem to be doing at the network level (separation,
fusion, learning), I've built into each node. So it's not like I've not
done many of the basic things you have done, I've just done it inside out
from how you are approcahing it. I've choosen to put things at the node
level, instead of the network level.

In all my experience with design work, I've found that the simpler design
is normally the better one. The design is not done until there is nothing
left to take out. The fact that you seem to need 6 modules, to do what I
figured out how to do in one, makes me believe I'm 5 modules ahead of you,
not 5 behind.

If you are right, I'll never get anywhere until I catch up to you, so you
have nothing to fear. What I say my net can do is not important. Unless
it actually starts to do something that I can demonstrate, it's all just
hot air.

--
Curt Welch http://CurtWelch.Com/
curt@xxxxxxxx http://NewsReader.Com/
.

Relevant Pages

  • Re: What did that thread indicate?
    ... You cannot do these things in the same network. ... >> must have multiple subnetworks feeding signals to one another. ... the output of every node in my network is doing signal separation. ... >So what you say "must" be done at the network level, ...
    (comp.ai.philosophy)
  • alt.2600 FAQ Revision .014 (2/4)
    ... register struct tcphdr *tcph; ... IP protocol (TCP or UDP) ... greatly increases the time required to scan your network. ... Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • alt.2600 FAQ Revision .014 (2/4)
    ... register struct tcphdr *tcph; ... IP protocol (TCP or UDP) ... greatly increases the time required to scan your network. ... Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • alt.2600 FAQ Revision .014 (2/4)
    ... register struct tcphdr *tcph; ... IP protocol (TCP or UDP) ... greatly increases the time required to scan your network. ... Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • alt.2600 FAQ Revision .014 (2/4)
    ... register struct tcphdr *tcph; ... IP protocol (TCP or UDP) ... greatly increases the time required to scan your network. ... Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)