shaunharker / DSGRN

Dynamic Signatures Generated by Regulatory Networks
http://dsgrn.readthedocs.io/en/latest/
MIT License
11 stars 16 forks source link

FC on a self-loop #2

Open breecummins opened 9 years ago

breecummins commented 9 years ago

Hey Shaun, here's the full command history and input file that produces the bug.

Command history from brand new terminal:

Last login: Thu Jul  2 10:12:24 on ttys000
[bcummins@breecummins ~]$ cd GIT/DSGRN/
[bcummins@breecummins DSGRN]$ ls
ACKNOWLEDGEMENTS      LICENSE               doc                   dsgrn_output.json     install.sh            source
CMakeLists.txt        README.md             dsgrn.session         include               networks              tests
INSTALL               build                 dsgrn_morsegraph.json index.html            software
[bcummins@breecummins DSGRN]$ rm dsgrn.session 
[bcummins@breecummins DSGRN]$ dsgrn network networks/6D_TwoWayForcing.txt 
[bcummins@breecummins DSGRN]$ dsgrn morsegraph json 4689
{"poset":[[1],[]],"annotations":[["FC"],["FP"]]}

Input file 6D_TwoWayForcing.txt:

X1 : ~Z1
Y1 : (~X1)(~X2)
Z1 : ~Y1
X2 : ~Z2
Y2 : (~X2)(~X1)
Z2 : ~Y2
shaunharker commented 9 years ago

It seems there are several kinds of mix-ups that can result in seemingly inconsistent output.

  1. Using for the Morse set index a value that is off-by-one (indexing starts at 0). (Evidently this is what happened in this case.)
  2. Switching directory (i.e. cd) to a folder with a different dsgrn.session file, inadvertently switching which network is being analyzed.
  3. Actually mixing things up. :)

I view (2) as being the biggest of these issues, since that seems like a pretty major gotcha. For (1) & (3) perhaps it is possible to make the output contain additional data making mix-ups less likely. It is unclear if this is always desirable though.

breecummins commented 9 years ago

Actually, point 1 was not the problem. I index by 0 routinely, not by 1. The problem was confusing the poset value with the index. I still think this is an outstanding issue:

{"poset":[[1],[]],"annotations":[["FC"],["FP"]]}

In the above output, I want the FC Morse set. Its index is 0, but its poset is 1. It is confusing which number I want for the Morse set.

shaunharker commented 9 years ago

The interpretation of

{"poset":[[1],[]],"annotations":[["FC"],["FP"]]}

is as follows:

There is a partially ordered set (the Morse graph) with two vertices, indexed 0 and 1. The "poset" value gives us a list of adjacency lists: [[1],[]] Vertex 0 has one out-edge, pointing to vertex 1. This is the information of the first adjacency list, [1]. Vertex 1 does not have out-edges. This is the information in the second adjacency list [].

The "annotations" value tells us: Vertex 0 has the annotation "FC". Vertex 1 has the annotation "FP".

Interpreting the adjacency list information attached to vertex 0 as instead being a label for vertex 0 leads to typing

dsgrn analyze morseset 1 4689

instead of

dsgrn analyze morseset 0 4689

in order to analyze the Morse set annotated "FC", which doesn't work.

I will consider this a bug in the documentation and change it to be more explicit about the list of adjacency lists representation of the poset.