Re: Nary trees

["Eric M. Monsler" <emonsler beamreachnetworks com>]

etienne buxin wrote:
> --- "Eric M. Monsler" <emonsler beamreachnetworks com> wrote:
> > A suggested structure:
> >
> > struct eb_manymany {
> >   uint			node_level;
> >   uint			num_parents;
> >   uint			num_par_max;
> >   struct eb_manymany	**par_ptr_array;
> >   uint			num_children;
> >   uint			num_child_max;
> >   struct eb_manymany	**chd_ptr_array;
> >   gpointer		data;
> > }
(snip)
> in fact, i'd like to create a structure to represent events.  i investigated trees because i need
> a parent-child relationship between events, with the parent event being a consequence of his child
> events.  Because one event may have several consequences, it must be able to have many parents (of
> different depht levels, moreover). i could duplicate the child for each of his parents, but this
> is not too good, because each event has _a lot_ of info carried with ( *data in glib's Nary tree)
> and this will consume a lot of ressources.
>
> has someone an idea?


The structure I proposed above should handle it, just remove the 
node-level.  Do you really mean that consequences are *parents* of 
events, not *children* of events?  My family tree reads differently, but 
whatever.

Let me call them causes and consequences, rather than parents and children.

If your set of operations is fairly limited, you should be OK.  For 
example, if the API was only Add(with list of causes and consequences 
pointers) and Remove(severing all cause/consequence, and also removing 
all unconnected nodes caused), it shouldn't be too complex.  Might be OK 
for creating a user-traversable set of nodes for a visualization exercise.

But, attempting to traverse the mesh is going to be a really tough problem.

Good luck.

Eric