KDA currently uses edge attributes to store/retrieve the edge weights and names. For example, say a graph has an edge connecting nodes 1 -> 2 with an edge weight of 10, the current approach will assign an attribute dictionary similar to the following:
attr_dict = {"name": "k12", "val": 10}
This works "fine", but at this point seems a little verbose/redundant when we have to use the edge indices (i.e. (0, 1) for this case) to retrieve this data in the first place. At that point we might as well just create the string using the indices (i.e. f"k{i+1}{j+1}").
Additionally, if we actually store the edge weights the way NetworkX intended, I believe we will have the ability to leverage more of their built-in utilities. That could prove useful if there is ever a spanning tree algorithm implemented there. I know there is already some work there, but last I checked there wasn't anything I could leverage. Most seemed to be min/max spanning tree-related things.
Lastly, I think we are currently iterating over the edges to collect their weights since there is no way to collect the values for a given attribute simultaneously. At least, of the top of my head, I believe that statement is correct. But the point is since we aren't storing that info as an attribute it should be easier to access and could potentially speedup some of the manual calculation functions, such as kda.calculations.calc_state_probs().
nawtrey
commented
2 months ago
KDA currently uses edge attributes to store/retrieve the edge weights and names. For example, say a graph has an edge connecting nodes 1 -> 2 with an edge weight of 10, the current approach will assign an attribute dictionary similar to the following:
This works "fine", but at this point seems a little verbose/redundant when we have to use the edge indices (i.e.
(0, 1)for this case) to retrieve this data in the first place. At that point we might as well just create the string using the indices (i.e.f"k{i+1}{j+1}").Additionally, if we actually store the edge weights the way NetworkX intended, I believe we will have the ability to leverage more of their built-in utilities. That could prove useful if there is ever a spanning tree algorithm implemented there. I know there is already some work there, but last I checked there wasn't anything I could leverage. Most seemed to be min/max spanning tree-related things.
Lastly, I think we are currently iterating over the edges to collect their weights since there is no way to collect the values for a given attribute simultaneously. At least, of the top of my head, I believe that statement is correct. But the point is since we aren't storing that info as an attribute it should be easier to access and could potentially speedup some of the manual calculation functions, such as
kda.calculations.calc_state_probs().