Browse Groups

• ## Thought experiment: a kind of Nv/Nu net/mesh

(2)
• NextPrevious
• Hi all, As some of you might know, I occasionally start thinking that experimenting with arbitrary nervous network nets or meshes might produce
Message 1 of 2 , May 1, 2004
View Source
Hi all,

As some of you might know, I occasionally start thinking that experimenting
with "arbitrary" nervous network "nets" or "meshes" might produce
interesting or useful results. With the notable exception of Scotty
Dogmabot (cute variation there...) and the Borg thing, I don't think that
many of such setups have been created. Usually, what I've seen is "modules"
of Nv/Nu stuff put together along with analog circuitry to produce a
definite effect: a complex device like Bruce Robinson's "Hider"

So... here is the most recent wild concept... Anybody have any thoughts
about it? Y'know, like "deVries, you really are an idiot, doncha know" or
better :-} deVries, your are amazing"

Um, really, I mean technical thoughts. Kindly ignore that silliness.

==========================================
Nv/Nu Network Process Avoidance/Routing Idea
==========================================

1) Start with a set of Nv neurons (Nv[1], Nv[2], Nv[3], ... Nv[n])

(note: all neurons are buffered to LEDs. Gotta make it a BLIFNAR, right?)

2) For some of those neurons (Nv[x]'s), choose two neurons (Nv[a],
Nv[b]) as
destinations

(note: this implies an absolute minimum of 3 neurons; practically there
would be
more)

3)For each the Nv[x]'s, monitor the output of the destination neuron Nv[a]

(note: the choice is arbitrary, however, I think it would be
more "appropriate"
somehow if Nv[a] is not busy that processes are sent to it. something
like
"don't bother it if it is already doing something")

(variation: each neuron could also have an associated Nu neuron; use it's
output for
monitoring; it might provide an interesting memory effect)

(variation: choose an arbitrary neuron Nv[y] (or Nu[y]) for monitoring,
i.e. not
a destination neuron)

4)If the monitored neuron is "not busy", route processes to Nv[a]
(74xx139 Dual
2/4 decoder??). If the monitored neuron is "busy", route process to Nv[b]

(variations: use an arbitrary number of destinations - two cases

a) destinations are grouped in two sets, the ones for "busy" and the ones for
"not busy" - watch out for fan-out problems

b) use several monitored neurons; their outputs are "decoded" to choose
some arbitrary destination neuron)

---

Problems/questions:
0) what the heck would this do?
1) avoiding hypersaturation
2) avoiding stasis (if desired)
3) determining (by experiment) if stasis is
achievable
4) determining how to get processes into some set of neurons (i.e.
"sensor input")
5) determine how to "mix" multiple inputs to a given destination
neuron. after all, any given neuron might have been chosen as
the destination
for more than one source neuron.
6) how does one build a "patch-panel" for a bunch of Nv's and Nu's and
routers? in
other words, how does one do this within a budget and within some degree of
construction perseverance. can you imagine building a Borg???

Note: the routing is generally independent of the processes (other than
they sort
of run it) - in other words, it directs processes but neither generates nor
extinguishes them.

spelling, grammar, stupidity problems all caused by being up at this hour
• In your thought experiment you raise the question/problem 2) how to avoid saturation. If this process avoidance/router has to interface with Nv/Nu logic, it
Message 1 of 2 , May 1, 2004
View Source
In your thought experiment you raise the question/problem 2) how to avoid saturation.

If this process avoidance/router has to interface with Nv/Nu logic, it may be worthwhile to review the basics.

Take the simple case of a series connected branch of grounded Nv neurons of some arbitrary length. Each Nv neuron has one input and one inverting output. The logical function of the common grounded Nv neuron is:

1) an inactive or reset Nv has a high output
2) a Nv process is triggered on a rising - low to high - edge at Nv input
3) the trigger generates an inverted active low Nv output pulse/process
4) a Nv process is reset after RC duration OR
5) a Nv process is reset by a high to low edge at Nv input

So for a high input pulse, a Nv will generate a low output pulse of a duration equal to the input pulse or the Nv R/C time constant, whichever is less.

When Nv neurons are connected in series, in strings or rings, the rising output at the end of each Nv process triggers the input of the next Nv neuron.

So what can an Nv process do for you?

The Nv process duration can be directly influenced by sensors which change the Nv R/C time constant.  Nv outputs can control LEDs or actuators (motor, etc).  A Nv output can trigger other logic including other Nv neurons. Nvs can be connected in branches or loops to form a complex pulse sequence generator(CPG).

Aside from the typical linear Nv core topology, Nv outputs can be connected to more than one Nv input and a treelike fractal structure is simple to achieve.

A mesh of Nv neurons such as the Borg, in which Nvs tricores are interconnected can can generate complex coupling behaviour in which the state of one tricore influences another  through coupling resistors or diode and depending on the phase and frequency can generate complex pulse patterns including chaos.

And so what information or message is being processed by Nvs let alone by Nv routers?

To paraphrase Marshall McCluhan, "The process is the message"  For now anyway since aside from beam robotics we are still looking for that killer app.

Ok, so much for the way Nvs behave, now onto the router question.

In general, a design is optimized for a specific application. In this case we are designing a kind of solution looking for a problem.

Based on the description, it sound a bit like a priority circuit like Bruce's h-switch which  ranks input sensor conditions and enabes  the highest priority sensor driven task.

In that case only one active output is permitted and a higher priority active output state disables all lower priority outputs via a daisychain inhibit signal.

The daisychain inhibit makes the h-switch scalable for connecting any number of h-switches in series.  Scalability is raised in your question 6:  "how to construct a router patch panel?"

Instead of the single output of an h-switch tree we want many parallel active outputs and the router actually functions to resolve conflicts when two Nv outputs (processes)  want to access the same Nv input. A daisychain can be used as a selector to route a coliding Nv output signal to  the next  available non-active input from a bank of parallel Nvs, which it then triggers. Once triggered that process cannot be affected by other processes other than the one that triggered it.
Therefore a falling edge reset signal from the input Nv can pre-emptively reset the associated output Nv an indeed, generate the transition cascade we call saturation.

Well that is it for a start.  Some circuits will follow. Let me know if this is useful.

regards

wilf
----- Original Message -----
Sent: Saturday, May 01, 2004 2:46 AM
Subject: [beam] Thought experiment: a kind of Nv/Nu net/mesh

Hi all,

As some of you might know, I occasionally start thinking that experimenting
with "arbitrary" nervous network "nets" or "meshes" might produce
interesting or useful results. With the notable exception of Scotty
Dogmabot (cute variation there...) and the Borg thing, I don't think that
many of such setups have been created. Usually, what I've seen is "modules"
of Nv/Nu stuff put together along with analog circuitry to produce a
definite effect: a complex device like Bruce Robinson's "Hider"

So... here is the most recent wild concept... Anybody have any thoughts
about it? Y'know, like "deVries, you really are an idiot, doncha know" or
better   :-}   deVries, your are amazing"

Um, really, I mean technical thoughts. Kindly ignore that silliness.

==========================================
Nv/Nu Network Process Avoidance/Routing Idea
==========================================
snipped
Your message has been successfully submitted and would be delivered to recipients shortly.
• Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
• Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer. We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.