Re: What did that thread indicate?

On 28 Sep 2005 20:24:22 GMT, curt@xxxxxxxx (Curt Welch) wrote:

>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.

This is nonsense.

>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 don't have this problem in my net. For discrete signal separation,
one must use a fixed time scale and a probabilistic correlation ratio.
The time scale is about 10 ms in humans. It means that, if a successor
signal arrive 10 ms after a predecessor, the signal is routed to the
output path. If not, the signal is blocked. Feedback must be used to
find correlations over longer time scales.

The proper correlation ratio is 10 to 1 (there is good reason for this
but that's another story).

Separation is a classification process. It routes signals into
individual paths. Why is it needed? Because signals arriving in any
sensory stream are mixed: they mean different things at different
times. After separation, it is important to fuse signals together
using coincidence detectors. Why? Because it is important to establish
context. Coincidence detectors are essential ALMOST cells. Why?
Because there is a lot of uncertainty in the sensory space.

>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.

It has nothing to do with feedback. It has to do with interval
recording.

[cut]

>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.

One cannot separate and fuse together at the same node. This is
nonsense.

>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.

Yes, simplicity is a must. But so is the logic of the design.

> 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.

You've done no such thing, Curt. It's all in your mind.

>If you are right, I'll never get anywhere until I catch up to you, so you
>have nothing to fear.

Why fear? I am not competing with anybody. I'd be delighted if you
solved the AI problem. I am an idealist. The world needs true AI,
desperately.

> 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.

No. If you have a valid idea, it's important. This is the reason that
I post here, to exchange ideas. I am not getting any good ideas from
you lately. Just a bunch of hollow claims devoid of logic. As always,
I tell it like I see it.

Louis Savain

Why Software Is Bad and What We Can Do to Fix It:
http://www.rebelscience.org/Cosas/Reliability.htm
.

Relevant Pages

  • Re: What did that thread indicate?
    ... > 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)