etienne buxin wrote:
>
> --- "Eric M. Monsler" <[EMAIL PROTECTED]> 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
_______________________________________________
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
