Enh/simplify node

[jakobj]

This PR implements abstract classes that make the definition of new nodes much easier and more compact. New nodes, i.e., operators can now be introduced in two lines:

class Add(BinaryOperatorNode):
    _def_output = "x_0 + x_1"

For operators that are "special", a few more lines are needed to define the different flavors for the to_... functions:

class Sqrt(UnaryOperatorNode):
    _def_output = "math.sqrt(x_0)"
    _def_numpy_output = "np.sqrt(x_0)"
    _def_torch_output = "torch.sqrt(x_0)"
    _def_sympy_output = "sqrt(x_0)"

or

class Parameter(NullaryParametrizedOperatorNode):
    _parameters = ("p",)
    _initial_values = (lambda: 1.0,)
    _def_output = "p"

Please have a look at the suggested implementation @mschmidt87 @HenrikMettler and let me know what you think. Is this approach sensible, user friendly, maintainable, flexible enough, etc pp?

Note that there still seems to be some duplication of code, however I am not sure how much further we can condense this while keeping the implementation (fairly) transparent.

closes #165

[mschmidt87]

Looks like a really good approach. I just have a few remarks, some are more minor:

• the file node.py is quite long. What about distributing the code over multiple files, for instance:
  • node.py for the basic Node class
  • node_derived.py (or a better name) for the derived classes Nullary, Unary, Binary, etc.
  • node_impl.py for the concrete instances
• I feel like we need a good mechanism to catch syntax errors in the strings of the class definition. What I mean is: What if the user makes a mistake in e.g. the _def_torch_output string. Now, I think that this will only fail when the to_torch method is called, perhaps after the entire evolution has finished. It would good to either check this at instantiation time or implement a check_class_definition method that can be called to check if a node definition is valid.
• [minor]: I would reorder the definition of the classes, such that it is Nullary -> Unary -> Binary
• regarding duplicate code: I would opt for reducing duplicate code as much as possible. We can mitigate intransparencies with good function names etc. For instance, parsing the inputs in the class definition can be outsourced from the classes, because it is the same code (just with different numbers of inputs).

[mschmidt87]

Oh and I would keep the definition of new nodes out of this PR, i.e. the Sqrt node.

[jakobj]

Thanks for the input! I followed your suggestion and created a unified NAryOperatorNode from which all other nodes are derived. The arity is now only defined in concrete subclasses that implement certain operators. I've also split the definitions across multiple files and added checks to make sure the operator definitions make sense. Also removed the Sqrt node again. please have another look @mschmidt87

[mschmidt87]

very nice. Just some minor points.

[jakobj]

thanks for the input @mschmidt87! i've implemented some of your suggestions and improved the doc slightly. please have another look!

[mschmidt87]

Approving with two (minor) requests:

1. Short explanation of the magic number in the test (either in the function or in a new fixture).
2. What about changing the title of the documentation about nodes to "Operator Nodes" now (instead of currently "Functional Nodes") since you introduced that class name in thisPR?

[jakobj]

ok, squashed my commits and removed the magic number again, it doesn't make sense here, you were right! let's see if travis is happy, then we can merge 👍