C++ Data Structures – Modeling a Network of Nodes and Edges

Assuming space is not a concern, would it be reasonable to create multiple copies of the graph (one for each user) rather than a single graph?

It seems to me that you should use what we could label ”layered graphs”, i.e. add a combinator for graphs, say @, so that:

• If A and B are graphs then A@B is also a graph (i.e. can be fed to the algorithms of your graph library).
• The set of vertices in A@B is the union of vertices in A and B.
• The set of edges in A@B is the union of edges in A and B.
• The structure A@B does not own any vertex or edge, but rather uses A and B as data containers.

With such layered graphs, you can define K to be the kommon available information and R, G, B each private information so that each player is actually seeing R@K, G@K, B@K.

To actually implement this, you may look for a graph library implementing algorithms generically, i.e. so that the longest path algorithm etc. are parametrised by the actual representation of your graph. So if your library says

ConcreteGraphAlgorithms = GenericAlgorithms(ConcreteGraphImplementation)

you can easily replace it with

LayeredGraphAlgorithms = GenericAlgorithms(LayeredGraphs(ConcreteGraphImplementation))

where you are supplying the LayeredGraphs and borrowing the rest from the library.

A regular tree would suit just fine and Approach 1 would work here. I think you should also read up a bit about the search algorithms used for a B-tree and then see how you could modify it here.

To me, this question is basically about how to modify a generalized B-Tree to handle properties with a propagation element.

Like you say:

• Store the tree as a regular tree.
• Store properties with the nodes they are set on.

But:

• Don't double link them - You can walk down the tree during the search (and also unfold if necessary revisiting the parent node when using typical recursive methods).

• Don't create a hash-table - a hash-table is just another look-up data-structure, why use it when you can modify the tree!

• DON'T DO THIS: Compute the properties inherited by nodes, by walking UP the tree ...

• INSTEAD DO THIS: Store the properties as you walk through the tree locating the target node. You have to visit them anyway. During the node traversal search just pass through the property if 'propagate' is on. When at the child node; don't save it if the property also exists there and is set to 'turned off'. Keep traversing until you reach your target node, storing the properties as you go (perhaps in some simple little list).

• Note that the property attributes requirements for 'propagate' and 'turned off' only impact the search algorithm by requiring logic to be placed in the traversal method.

PROBLEM 1: Computing properties on a set of nodes is slow. Dumb implementation results in O(PDN) although I have a feeling this can be improved.

• SOLUTION: This is full of assumptions. What is a set? I only can assume a simple case like; set of nodes are all of the direct children of their parent node & depth of 1. Given this; Locate the parent node first with all the properties saved up until that parent node (as we just discussed in the previous point). Then for each child of that node you calculate out the properties - so for each child you have all the saved properties up to that parent node + the child's properties.

• EXAMPLE: Traverse from the root node to a target node. For each node get the properties where they are 'propagated' and then traverse the next node passing through those properties. For the next node; for each property passed through check they are in the current node, if they are present and are 'turned on' then overwrite the property with the current nodes value. Then do the 'propagation' check and redo going through the nodes until the target node. Then you are left with the children - apply the same attribute logic and record the properties for each node.

PROBLEM 2: Finding out which nodes inherit a specific property in the whole tree is VERY slow and I don't see a good way to optimize it.

• SOLUTION: Here, you want to search for this efficiently but the creation of your tree solution doesn't have to be so efficient. And it's not too complex because you just need to find if it is 'turned off' or not - and not involve the 'propagate' property. What you need to do here is use the tree as it is supposed to be used. If a property is not 'turned off' you want to say to the parent node that a child of theirs has a specific property and then update all the way back up to the root node. This way if a property doesn't exist at all you'll know straight away when visiting the root node that it doesn't exist.

• EXAMPLE: Given a child node is set with a new property and 'turned on'; update the parent node with the same property and set to 'turned off' and use this to say the property exists in one of the nodes children. Then for each parent above that parent, set the same property and attribute. Now start to traverse from the root node the property will be set on the root node indicating that a descendant has that property. Do a traversal search and go through each child where the property is set - store each node where the property is 'turned on'.

Hopefully I can improve on this answer. Help me by indicating hard to understand parts of my answer.