Re: What did that thread indicate?

Traveler <traveler@xxxxxxxxxx> wrote:
> On 29 Sep 2005 05:07:17 GMT, curt@xxxxxxxx (Curt Welch) wrote:

> >> One cannot separate and fuse together at the same node. This is
> >> nonsense.
> >
> >You really are clueless about what I'm doing aren't you? It strikes me
> >as odd that you would be want to make such strong statements about
> >something you don't understand.
>
> That's because I know what discrete signal separation and fusion mean.

Ok. Clearly, when you use those words, you do not see the same ideas I
see.

> Signal separation does not mean splitting an input signal into two. It
> means to pluck a signal from a single incoming stream of signals and
> send it down a separate path. Signal separation cannot be done using a
> single input stream. It requires two input streams. Why? Because there
> must be a temporal correlation between two different signals in very
> close temporal proximity (contiguity).

Ok, I don't see it like that all.

If you have a audio stream of cocktail party noise, a general AI network
needs the power to separate the single data stream into separate
conversation. This is signal separation. It's a filtering processes. But
when people say "filter" they normally mean, separate the signal into two
parts, and then throw one part away. The general solution however needs
"tunable filters" which spit signals.

Taking a single radio signal and filtering into separate stations, is a
signal separation processes. It can and must be done single signals and
does not require two signals to do.

Combining the audio streams togther in an audio mixer is an example of
fusion. It's the exact inverse signal separation. It takes two signals,
and combines them together.

> Likewise, signal fusion is not about merging two signals into a single
> stream. Fusion is about finding coincident (simultaneous) signals and
> combining them into a single signal. Both operations require a
> temporal learning rule and a correlation factor. Signal fusion
> necessarily must come after separation. That's because the correlation
> factor would not work otherwise.

Yes, I looked at the problem of how to separate and fuse data together for
years because I felt the solution to AI required a machine that could take
sensory data, separate it into primitive components, and then throw way the
stuff that was of no interest, and fuse together the stuff that was needed,
to define the correct outputs.

In addition, I felt the speration and fusion needed to be all under the
control of reinforcement learning, so the system could learn which parts of
the sensory data were important to separate out, and learn, which parts
were important to fuse back together to define the current behavior of the
system.

Now, if you look at the data as a typical digital data stream, we are
taught to think about it as a sequence of values, with a new value showing
up on a constant regular basis. So whether the values are binary bits,
that show up at 44100 bits per second, or whether it's dual 16 bit values
showing up 44100 samples per second, it's still a complex and constant flow
of data.

If look at it like that, there is a nearly endless and infinite number of
filtering and combining algorithms to pick from. You can do frequency
domain filtering of any multi-pole filter shapes you want to build with the
data. Or you could pick every other bit out of the data stream. The
question kept asking myself, is how can the system be smart enough to find
anything hidden in the data and separate it out?

Then I started looking a pulse based signal formats instead of value based
fixed sample frequency signals that were so commong in digital signal
processing and computers.

What I realized, was the pulse signal had some really nice properties. All
the data was nicely packed not into values, such as the two state binary
bit, or a 65536 state 16 bit data word, but instead to uniary state pulses.
This meant that the pulse had no "value" in the spatial domain like our
normal signal formats. It's only "value" was it's location in time.

What I started to see, is that to separate these signals into their base
components, all you had to do was, pick out pulses, and send them a
different way. There was no "value" to do a calculation on. Routing the
pulse, was the only thing you could do to it. So, the only way to separate
a pulse based signal, without loosing information, or adding more
information, was to select each pulse and either leave it as part of the
signal, or take it out, and make it a new signal. So all of a sudden, the
problem of "signal separation" became a whole new, and much simpler, game.
Instead of trying to figure out which of an infinite list of complex math
forumlas to apply to the "values" in a data stream in order to correct
separate it, the problem became one of making simple binary routing
decisions for each pulse.

Now, there are still an infinit number of complex algorthms you could
develop for pulse separtion. For example, you could keep a running average
of the pulse spacing and pull out all the pulses that show up when the
running average drops below a constant. Or you could keep a short term and
a long term running average and pull out pulses whenever the short term
average is higher than the long term average. Or, I could, as you said,
look at two signals, and separate the pulses in the first signal, based on
something happening in the second signal, like it's correlation to the
first signal. The list goes on and on. I spend a a year or two playing
with different pulse separation ideas.

But, the more I looked at this, the more I felt that all the rules based on
more than just the last pulse, could in fact be defined in terms of simpler
rules, which only worked on the last pulse. So instead of a function based
on the timing of the last 5 pulses, I felt the most primitive and best
system was one which based it's timing on only the last pulse (meaning the
spacing between the current pulse, and the one which came before it).

This also had the advantage of the fastest reaction time. Anything based
say the average of the last 3 pulses, might not react to a change in the
pulse patterns, until 3 pulses showed up. By basing it only on the last
pulse, then the node reacts instantly, to a change in data - leaving the
"slower" reaction, to becoming a network function created by the combined
actions of multiple nodes.

And for signal fusion in the pulse domain, all you have to do is combine
pulses from separate signals, into one signal. It's even simpler and more
fundimential than summing value streams. And once again, where as in teh
value, stream, there is an infinite number of functions that can be used to
fuse signals today (sum, xor, and, or, sqrt(x^2+y^2), etc), in the pulse
domain, there is one, and ONLY ONE way to fuse two signals without adding,
or loosing or temporal smearing of the data.

What, what I figured out, was that when we did this separation and fusion
processes in a pure pulse signal domain, the problem which looked so
impossibly hard in the value domain, bcamse out right trivial in the pulse
signal format domain.

And the big win, comes from the fact, that the "separation" algorthm,
because it's so simple, is now ideal to shape with reinforcement learning.
If you look at a dignal filter working on a value stream, how do you shape
it with reinfrocement learning? If the filter is "punished", how should it
change it's frequency domain filter characteristcs in resposne to the
punishement? There's no easy answer to this because the filter is defined
by a complex high dimenstional fuction so you have no clue which dimenstion
to change, and in which direction to change it.

But with pulse separation, it can be a low dimenstion simple binary
decision. Each pulse must be separated to either signal path A, or signal
path B. If th current system sent it down path A, and that behavior was
punished, the answer of how to respond to the punishment is obvious, you
should sort less pulses down path A in the future and more pulses down path
B.

Now, Louis, you talk about your ying and yang. Notice how beautifuly
simple and semetcial this is. Pulse separation happens by sorting pulses
from one path, down to two paths. PUlse fusion happens by sorting pulses
from two paths, into one path.

Punishment causes less pulses to go down the same path, but more down the
other. So to punish a sort of the pulse down path A, is the exact same
thing rewarding, a sort down path B. And rewarding a sort down path A, is
the exact opposit of punishing a sort down path B, but just the opposit of
punishment. It's all perfectly semetrical and balanced.

At the same time, the separation algorithm is now a programable filter,
under the control of reinforcement. So the system learns, from
reinforcment, what data to use, and what data to ignore. But by "ignore"
the sytem just means, "try to send it somewhere else to see if it can be
made use of elsewhere".

So where as I feel I've found the simplest and most fundimital way to do
signal separation and fusion possible (which is all a fall-out of switching
to pulse based signals) I see you as stuck playing around with value
networks which are only a poor emulation of a true pulse network because
you still think pulse "values" all show up the same time to a set of inputs
as if they were sychronous values instead of truely asyncronous pulses.

I've tried multiple times to open your eyes to fact that you still have one
foot stuck in the spatial value processing paradigm because you expect
"values" to show up, "at the same time" and if you just pull your foot out
of that crap, everything that was one so hard in the value domain, becomes
trivial in the pulse domain.

"Correlation" in the pulse doamin doesn't mean "at the same time". It
means "close together in time". And my nodes do correlation based signal
separation by splitting the correlated pulses (the ones that are close in
time) into a separate signals, from the ones which are uncorrelated (far
apart in time). So the natural function of the net, is to separate signals
into components, and recombine them based on correlation.

Everything you keep saying must be part of the system, I see happening in
my net, and I see it happening in ways that seem far simpler and far more
fundimential than what you seem to be doing (though you never give us full
details of your algorthms so I never know for sure what you are in fact
doing). You however, only seem to see your way of doing signal separation,
and if I don't do it your way, you don't even see my function as
"seperation".

As I said, if I'm not doing it your way, you don't think I'm doing it at
all. You are making a mistake by not seeing that there are many different
ways to skin the cat here.

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

Loading