An infinite loop in Succession Diagram construction

[jcrozum]

I think this is fixed in this branch: infinite-succession-loop-fix, but I need to do more testing.

There were two issues: 1) some 0 and 1 values were still written as "0" and "1", and 2) the percolation was only percolating the stable motif currently considered, and not the "upstream" stable motifs.

The fix I have in the branch above is a little bit inelegant; I basically just make it percolate everything from scratch. A better solution would probably be to add an option to the percolate_network option to remove constant nodes.

[jcrozum]

I forgot to mention, the network I was testing on was this one:

x1, x2
x2, x1
x3, x1 | !x4
x4, x3
x5, x2 & x6
x6, x5

This is the same as the one in fig. 3 of this paper. Note that the succession diagram structure is slightly different because we have not yet implemented feed-forward detection yet, meaning there will be two copies of the orange node.

[jcrozum]

@daemontus is there an easy way to remove a constant node from an AEON BooleanNetwork object?

To me, it looks like I'd have to basically make a copy of it and skip the constant nodes while making the necessary changes to the regulatory graph by-hand. If that's the case, maybe it's better to just keep track of 'frozen' nodes separately.

[daemontus]

Right now, making a copy without the node is probably the only option. We didn't initially support node addition/deletion because it opens a whole can of worms regarding when should a node be allowed to be added/deleted w.r.t. existing regulations/update functions (i.e. restrict deletion to nodes with no interactions, or do we perform some best effort recursive/transitive deletions, etc.). Plus our VariableId references may break by doing this (i.e. you'd need to track what was deleted/added to resolve what is a valid variable). Overall, it just seemed like too much space for introducing bugs at the time.

But it would be nice to support it at some point. So maybe I can have a look and add the functionality if we have a clear idea when the deletion should be allowed/be reasonably safe.

[jcrozum]

Okay, that makes sense. I'll continue with my approach then. I still need to check that I'm not doing extra percolation steps, and I'll probably want to add an option to the the Trappist function to ignore constants completely. Right now, I'm filtering out the trap spaces that correspond to constants after they're returned; it would be better to have the option to treat them as "removed" from the network.

[jcrozum]

Fixed in #43