Closed siyuzhou closed 6 years ago
I am making changes to the neighbors function in three classes LogicNetwork
, WTNetwork
and ECA
to address the issues above and other minor performance issues. I am finished with LogicNetwork
and WTNetwork
and am reviewing the ECA
part. @hbsmith I noticed you extended the lattice list with its boundary conditions such that the actual list contains [node1, node2, ..., nodeN, left_boundary, right_boundary]. Can you explain why you designed the list like this? Is it the convention for ECA? If not, I feel it is counter-intuitive they way they are ordered and confusing to users when they see a returned index greater than the possible index of the lattice. Also, what are the reasons for which we decide to include boundary conditions in the neighborhood, despite they are not part of the ECA? This is an interesting question, especially since our last GRN meeting, because this can affect our interpretation to the "external" nodes in other types of networks. Do we treat them as environmental conditions outside the "core" network, whose dynamics is not self-contained?
Addressed by pull #91
Right now the
neighbors
function in the network classes' definition check if the user wants to return neighbors of a specific index or the neighbors of all the nodes of the network. Personally I prefer not to have the function return all the neighbors.There is no immediate benefit to return the neighbors of all nodes as a whole. A user would still need to dive into the returned list and read the neighbors of each node one by one. Considering that
neighbors
already needs afor
loop to traverse all the indices, and that the exactly samefor
loop is executed twice, it is more advantageous to just callneighbors
at a specificindex
each time:is better than
If we only use
neighbors
function for a specificindex
, we can also drop theif
statement to gain a minor performance boost besides cleaner code.