ELIFE-ASU / Neet

Simulating and analyzing dynamical network models
https://neet.readthedocs.io/en/stable
Other
4 stars 10 forks source link

`neighbors` function #90

Closed siyuzhou closed 6 years ago

siyuzhou commented 6 years ago

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 a for loop to traverse all the indices, and that the exactly same for loop is executed twice, it is more advantageous to just call neighbors at a specific index each time:

for i in range(net.size):
    # Do something with net.neighbors(i)

is better than

for neighbors_i in net.neighbors():
    # Do something with neighbors_i

If we only use neighbors function for a specific index, we can also drop the if statement to gain a minor performance boost besides cleaner code.

siyuzhou commented 6 years ago

I am making changes to the neighbors function in three classes LogicNetwork, WTNetwork and ECAto 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?

siyuzhou commented 6 years ago

Addressed by pull #91