A somewhat safer handling of AEON partially specified networks

[daemontus]

Hi!

So I started working on the promised review of the AEON support in bonesis... I believe the most crucial part is the new translation function which should explicitly check some of the conditions which were previously only assumed in comments.

However, I have seem to run into two issues which I tried to include in the tests, but I need help resolving:

(1) If the network contains a partially specified function that is not fully unknown (i.e. something like A & f(B,C)), the boolean_networks view does not really work: it can count the networks, but it can't print them because the clauses have extra data and the translation fails somewhere in asp_encoding.py. This seems like something that never really got implemented because the usage of AEON input files was so untypical? If you tell me how to interpret those clauses (they seem to have a tuple instead of a simple clause index), I can probably do that myself, but I'm not 100% sure what the tuple means.

(2) This is probably not a bug, but a "limitation" of bonesis, but if there is some easy fix for it, it would be very helpful... It is currently possible to input a network with inconsistent regulation constraints (e.g. A -> B and $B: !A), and bonesis will just ignore that regulation and consider the network to be valid. Of course, this is not a big deal in such a simple case, but it then translates to other instances where unknown functions are involved. For example, with A -> X, B ->? X, and $X: !A & f(B), this still reports valid solutions. Furthermore, with $X: A & f(B) it counts the constant function f=0 as a solution, even though it makes the result not depend on A. So... I understand that it's not easy to account for all of these cases in a trivial way, but I was wondering whether there is some sort of mechanism that could help to mitigate this.

First, clearly we could do a safety check that all explicit, DNF encoded functions respect the monotonicity that is prescribed for them and simply fail during encoding if this is violated (similar to the "negation of parameters" check). This would solve the first two problems, because it would detect that A is used negatively even though it is a positive regulator. I'll be happy to add that if you think it would be useful. What I'm not sure about is the last problem, because that would probably require some extra ASP constraint that says "A is essential input of A & f(B)" on top of saying "B is non-essential input of f" (which bonesis already does). Do you have some idea of how to add such constraint?