Re: Name that data structure!

Robert Dober wrote:
> Sounds like a marked graph to me, and not directed at all, or did I
> miss the arrows? That of course is a very general
> thing, I therefore doubt that this statement is helpfull.
> I do not understand with what you mean that a node can be connected to
> a group of nodes?
> Do you mean that if the nodes are e.g. lower case letters, there might
> be an edge X in e(a,{b,c}) (X being the marking)
> without implying that there is X in e(a,b) and X in e(a,c)?
> If that is the case you still have just a general graph only that you
> have to expand the nodeset to its powerset.
>
> Cheers
> Robert
>
>   
Robert,

I apologize for my mathematical illiteracy. I don't understand your 
question, because I don't understand your symbolic representation. Sorry.

So, allow me to explain it in terms I do understand - in the terms I'm 
using to work out the problem as I program the solution. Please realize 
that this may or may not well relate to the structure Simon's interested 
in. I think it does, but that's for him to say. For me, it's a practical 
problem in highly flexible information storage and retrieval, and a good 
chance for me to advance my Ruby skills. Here's a fundamental 
specification for the model I'm implementing:

* A "node" is a unit of information. It can be anything: a word, phrase, 
number, equation, pointer to something else - anything. It's just 
something that can be connected (related) in some way to another node.
* I indicate a node like this: .n {information}
* The node indication begins with the first character after the space 
following node indicator, and ends when another indicator or an EOL/CR 
is read,
* I indicate a relationship similarly: .r {information}

I now can specify node relationships. Some examples:

.n Tom .r is a .n poor programmer
.n apple r. is not .n bridge building material
.n e=mc**2 .r could be .n true

Obviously, these aren't sentences, so we do not use articles, 
conjunctions, and the like.

Simple enough. Now, consider this:

I start with a database of nodes, and of relationships - note that each 
gets a unique ascension number:
n1 {}
n2 {}
n3 {}
...

r1 {}
r2 {}
...

When I specify a relationship with a node not in the database of nodes, 
it gets inserted there; ditto for relationship types (NOT to be confused 
with relationships - which are sets of two nodes linked with a 
relationship of a given type).

Relationships ALSO go in a database, and each also gets a unique 
ascension number.

Here's three complex relationships, each with its number (I preface 
relationship ascension numbers with a lowercase L - for link):

l43 n1 and n2 and n3 .r are .n true
l44 n4 and n5 and n5 .r are .n not true
l45 l44 and l43 .r are .n true

The last one is the form of a line detector in the human eye, a simple 
but vital element or our brain. That's not my interest, but I AM 
interested in being able to build structures LIKE this, and I think this 
sort of cascading complexity is what Simon is getting at. I think of it 
as a sequential sparse matrix, but what do I know? I probably have that 
all garbled, but the logic itself I'm sure of. This WILL work, though it 
well may not be optimal in my specification of it. I'm simply trying to 
follow the maxim of 'get it to work, first', then 'get it to work well, 
later'.

So, I'll stop here, and wait for comment, if any.

t.

-- 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Tom Cloyd, MS MA, LMHC - Private practice Psychotherapist
Bellingham, Washington, U.S.A: [phone]
<< [e-mail] >> (email)
<< TomCloyd.com >> (website) 
<< sleightmind.wordpress.com >> (mental health weblog)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~