How to represent `if` - `elif` - `else`

[samwaseda]

Now we come to the final part of our trilogy. Let's take the following example:

def my_condition_one(x, y):
    return x > y

def my_condition_two(x):
    return x > 0

def add(x, y):
    return x + y

def multiply(x, y):
    return x * y

def my_workflow(x, y):
    if my_condition_one(x, y):
        result = add(x, y)
    elif my_condition_two(x):
        z = multiply(x, y)
        result = add(x, z)
    else:
        z = add(x, y)
        result = multiply(y, z)
    return result

Following the structure of while (cf. #24), the three blocks are wrapped in independent injected nodes:

• if-node
  • test
  • body
• elif-node
  • test
  • body
• else-node
  • body

(body stands for inputs, outputs, nodes and edges)

That means the whole thing would look like this:

{
    "inputs": {"x": {}, "y": {}},
    "outputs": {"result": {}},
    "nodes": {
        "injected_if_0": {
            "test": {
                "function": my_condition_one(x, y),
                "inputs": {"x": {}, "y": {}},
                "outputs": {"output": {}},
            },
            "inputs": {"y": {}, "x": {}},
            "outputs": {"result": {}},
            "nodes": {
                "add_0": {
                    "function": add(x, y),
                    "inputs": {"x": {}, "y": {}},
                    "outputs": {"output": {}},
                }
            },
            "data_edges": [
                ("inputs.x", "test.inputs.x"),
                ("inputs.x", "add_0.inputs.x"),
                ("inputs.y", "test.inputs.y"),
                ("inputs.y", "add_0.inputs.y"),
                ("add_0.outputs.output", "outputs.result"),
            ],
            "label": "injected_if_0",
        },
        "injected_elif_0": {
            "test": {
                "function": my_condition_two,
                "inputs": {"x": {}},
                "outputs": {"output": {}},
            },
            "inputs": {"y": {}, "x": {}, "z": {}},
            "outputs": {"result": {}, "z": {}},
            "nodes": {
                "multiply_0": {
                    "function": multiply,
                    "inputs": {"x": {}, "y": {}},
                    "outputs": {"output": {}},
                },
                "add_0": {
                    "function": add,
                    "inputs": {"x": {}, "y": {}},
                    "outputs": {"output": {}},
                },
            },
            "data_edges": [
                ("inputs.x", "test.inputs.x"),
                ("inputs.x", "multiply_0.inputs.x"),
                ("inputs.x", "add_0.inputs.x"),
                ("inputs.y", "multiply_0.inputs.y"),
                ("multiply_0.outputs.output", "add_0.inputs.y"),
                ("multiply_0.outputs.output", "outputs.z"),
                ("add_0.outputs.output", "outputs.result"),
            ],
            "label": "injected_elif_0",
        },
        "injected_else_0": {
            "inputs": {"y": {}, "x": {}, "z": {}},
            "outputs": {"result": {}, "z": {}},
            "nodes": {
                "add_0": {
                    "function": add,
                    "inputs": {"x": {}, "y": {}},
                    "outputs": {"output": {}},
                },
                "multiply_0": {
                    "function": multiply,
                    "inputs": {"x": {}, "y": {}},
                    "outputs": {"output": {}},
                },
            },
            "data_edges": [
                ("inputs.x", "add_0.inputs.x"),
                ("inputs.y", "add_0.inputs.y"),
                ("inputs.y", "multiply_0.inputs.x"),
                ("add_0.outputs.output", "multiply_0.inputs.y"),
                ("add_0.outputs.output", "outputs.z"),
                ("multiply_0.outputs.output", "outputs.result"),
            ],
            "label": "injected_else_0",
        },
    },
    "data_edges": [],
    "label": "my_workflow",
}

Consideration: As we can see already at this point, we actually have to wrap the whole blocks as an injected if block, because there is no edge from the global input to the if blocks, as well as the if blocks to the global output. We could potentially do the same with the while loop. Otherwise I don't necessarily see a problem here. What do you think?

[liamhuber]

@samwaseda, at first glance I don't see anything I dislike with the syntax. As with while, I think it's important to nail down what constraints we're imposing beyond python:

• The body must be declarations and function calls (as with all macros(?))
• The condition must be a boolean-returning function call (as with while)
• Every body must return the same number of values with the same names
• The macro return type must be a union of all clause return types for each returned channel

An alternative idea would be to have the wrapping macro keep outputs for all clauses separately, but only the activated clause would ultimately receive data. The pro is that then the clauses are free to return more and different things if they want. This would relax the third and fourth conditions together into a single condition like

• The macro output channels must be the type-differntiated union of all clause output channels

The con is that this would involve all engines having a concept of non-execution. In a pyiron_workflow paradigm, this will probably work fairly well as we already have the idea of NotData and ready, such that anything downstream of the inactive clauses would not wind up getting executed because it would still be receiving NotData input and thus never identify as ready. I don't know if such concepts are sufficiently universal to exploit here.

[samwaseda]

Maybe I'm gonna clarify the difference that I see for the nesting between if/else and while (which is not reflected in my example above, because I tried to give it the same structure as while):

For while:

• workflow
  • while
    • test
    • body

For if/else:

• workflow
  • if-else
    • if
      • test
      • body
    • else
      • body

The reason is because contrary to the case with while, where the output of the while body can be directly connected to the input of the next line, in if/else the outputs must be first unified to be passed to the next line. I don't think it's a deal breaker, but it's somewhat unintuitive.

[samwaseda]

Based on my comment above, the full representation would look more like this:

{
    "inputs": {"x": {}, "y": {}},
    "outputs": {"result": {}},
    "nodes": {
        "inputs": {"x": {}, "y": {}},
        "outputs": {"output": {}},
        "injected_if_0": {
            "if": {
                "test": {
                    "function": my_condition_one(x, y),
                    "inputs": {"x": {}, "y": {}},
                    "outputs": {"output": {}},
                },
                "inputs": {"y": {}, "x": {}},
                "outputs": {"result": {}},
                "nodes": {
                    "add_0": {
                        "function": add(x, y),
                        "inputs": {"x": {}, "y": {}},
                        "outputs": {"output": {}},
                    }
                },
                "data_edges": [
                    ("inputs.x", "test.inputs.x"),
                    ("inputs.x", "add_0.inputs.x"),
                    ("inputs.y", "test.inputs.y"),
                    ("inputs.y", "add_0.inputs.y"),
                    ("add_0.outputs.output", "outputs.result"),
                ],
                "label": "if_0",
            },
            "elif_0": {
                "test": {
                    "function": my_condition_two,
                    "inputs": {"x": {}},
                    "outputs": {"output": {}},
                },
                "inputs": {"y": {}, "x": {}},
                "outputs": {"result": {}},
                "nodes": {
                    "multiply_0": {
                        "function": multiply,
                        "inputs": {"x": {}, "y": {}},
                        "outputs": {"output": {}},
                    },
                    "add_0": {
                        "function": add,
                        "inputs": {"x": {}, "y": {}},
                        "outputs": {"output": {}},
                    },
                },
                "data_edges": [
                    ("inputs.x", "test.inputs.x"),
                    ("inputs.x", "multiply_0.inputs.x"),
                    ("inputs.x", "add_0.inputs.x"),
                    ("inputs.y", "multiply_0.inputs.y"),
                    ("multiply_0.outputs.output", "add_0.inputs.y"),
                    ("add_0.outputs.output", "outputs.result"),
                ],
                "label": "elif_0",
            },
            "else": {
                "inputs": {"y": {}, "x": {}, "z": {}},
                "outputs": {"result": {}, "z": {}},
                "nodes": {
                    "add_0": {
                        "function": add,
                        "inputs": {"x": {}, "y": {}},
                        "outputs": {"output": {}},
                    },
                    "multiply_0": {
                        "function": multiply,
                        "inputs": {"x": {}, "y": {}},
                        "outputs": {"output": {}},
                    },
                },
                "data_edges": [
                    ("inputs.x", "add_0.inputs.x"),
                    ("inputs.y", "add_0.inputs.y"),
                    ("inputs.y", "multiply_0.inputs.x"),
                    ("add_0.outputs.output", "multiply_0.inputs.y"),
                    ("multiply_0.outputs.output", "outputs.result"),
                ],
                "label": "else",
            },
        },
        "data_edges": [
            ("inputs.x", "if.inputs.x"),
            ("inputs.y", "if.inputs.y"),
            ("inputs.x", "elif_0.inputs.x"),
            ("inputs.y", "elif_0.inputs.y"),
            ("inputs.x", "else.inputs.x"),
            ("inputs.y", "else.inputs.y"),
            ("if.outputs.result", "outputs.result"),
            ("elif_0.outputs.result", "outputs.result"),
            ("else.outputs.result", "outputs.result"),
        ],
        "label": "injected_if_0",
    },
    "data_edges": [
        ("inputs.x", "injected_if_0.inputs.x"),
        ("inputs.y", "injected_if_0.inputs.y"),
        ("injected_if_0.outputs.result", "outputs.result"),
    ],
    "label": "my_workflow",
}

And I silently also removed z from the output dict, which we decided to return as an output in the previous discussion, but I just think it's super dangerous to ask for z when it clearly is not created depending on the case.

[liamhuber]

#24

Consider the following:

def my_workflow(x, y):
    a = my_initializer(x, y)

    if my_condition_one(x, y):
        result = add(x, y)
    elif my_condition_two(x):
        z = multiply(x, y)
        a = add(y, z)
        result = add(x, z)
    else:
        z = add(x, y)
        result = multiply(y, z)

    return ???

In this case, I feel that it's fine for ??? to be result, a, because both of these are guaranteed to be available by the end of my_workflow. On the other hand, result, a, z should be disallowed because z is not guaranteed to exist.

But this means that the injected if node can only be adequately parsed in the context of what siblings it has in the scope of my_workflow -- otherwise how will it know that it needs to return a but not z?

I think we face an analogous problem in

def my_other_workflow(x, y):
    a = my_initializer(x, y)

    while my_condition(x, y):
        x = add(x, y)
        a = multiply(x, y)
        z = multiply(a, y)

    return ???

We can certainly return x and a, but in case my_condition starts false we mustn't return z. But the safety of the injected while-loop returning a is only known by examining the sibling "my_initializer_0" assignment...

[samwaseda]

In this case, I feel that it's fine for ??? to be result, a, because both of these are guaranteed to be available by the end of my_workflow. On the other hand, result, a, z should be disallowed because z is not guaranteed to exist.

💯

We can certainly return x and a, but in case my_condition starts false we mustn't return z. But the safety of the injected while-loop returning a is only known by examining the sibling "my_initializer_0" assignment...

That doesn't sound like a problem to me. If while is not executed even once, the input a is simply returned as the output a. On the other hand, I realized that there would be a problem in the following case:

def my_workflow(x, y):
    a = my_initializer(x, y)

    if my_condition_one(x, y):
        result = add(x, y)
    elif my_condition_two(x):
        z = multiply(x, y)
        a = add(y, z)
        result = add(x, z)

    return ???

As else is not included, result might not be defined. That would basically mean the local variables are returned only if else is given. That sounds like a source of huge confusion.

I jumped from one option to another multiple times within 24h now, but now I'm starting to feel that in the end we might indeed have to check whether the variables are used in the subsequent code.

[liamhuber]

but now I'm starting to feel that in the end we might indeed have to check whether the variables are used in the subsequent code.

And the prior code. Yep, I am pessimistic that we can escape without examining the sibling scope.

[samwaseda]

What I don't know for now in this PR is what to call it if there are multiple elif. Let's take this as an example:

def my_function(x):
    if ...:
        ...
    if ...:
        ...
    else:
        ...
    return ...

So there are two if statements and one else which is attached to the first if. In this case, the first if statement gets the tag injected_If_0 and the second one injected_If_1, but the else becomes injected_Else_1, because it is associated with the second if. With this argument, elif should in principle be injected_Elif_i, but since there could be multiple of them, we might need one more index, so injected_Elif_i_j? What do you think? @liamhuber

[samwaseda]

I just realized one thing. With if - else we definitely have two sources for a node:

def f(x):
    if x < 0:
        y = g(x)
    else:
        y = h(x)
    return y

So y has the output of g or h, and the edges have to be given accordingly. It's not necessarily a problem, but goes against our paradigm.

[liamhuber]

Now that pyiron_workflow has both While and For node classes that remove the need for the user to touch signal edges, I've been thinking a lot about if both in that context and this one. I believe it will be useful to think about both the semantikon.workflow and pyiron_workflow implementations simultaneously -- as much as it's nice for the semantikon.workflow representation to be readable and intuitive, what we need is just to represent the minimal necessary information for downstream engines to construct an if flow control. By thinking about both sides at once, I hope we'll be less likely to gloss over information the engines actually need, while at the same time we can think about what parts of the complexity we can simply delay until the engine's parse it -- i.e. we are free to say "well, this looks a little funny, but everything you need is here, so have at 'er".

I'm not sure the engine perspective gives us a clear answer yet, but let me put on my engine-hat and see how far I get....

I think each if-clause, in order to be unambiguous in its interface and execution, requires

• $N>=1$ condition cases -- i.e. converting x < 0 into an operator node, or directly using some_condition in the examples above
• $N + 1$ body cases -- the minimal if body, the explicit else case, and then one for each elif when N>1
• At this point, it is easy to map the input for our If node by prepending the condition and body node inputs -- condition0_foo, body0_bar, body1_bar, body1_boa, etc.
• At this point, there are two mutually exclusive "obvious" choices for defining the output:
  1. Follow the input pattern, and freely expose scoped body output -- body0_x, body0_y1, body1_some_output`,
  2. Demand at the time of parsing the If macro, that all bodies have the same number of outputs (types can be combined with an |) and just enumerate on those -- i.e. result_0 in our examples above that set y=.

I think that we can again follow python (or at least common linters) to rule out (1). Consider

def sometimes_fails(x):
    if c(x):
        a = f(x)
        b = g(x)
    else:
        a = h(x)
    return a, b

Python will let you write this you're an adult, but it will plausibly fail at runtime and every linter and IDE will yell at you. In this way, since we are building a workflow framework I think it's very fair for us to carry the linters and IDEs complaints further and simply say "no". I mean, consider the perspective of the engine -- if it has all these outputs -- body0_x, body0_y1, body1_some_output -- but some of them never get populated, what's it supposed to do? Have an "if they got filled" operation? That's the damned If node to begin with! It's turtles all the way down.

Even with the more rigid approach, I'm not clear how this will work with type-hinted expectations, and I have no idea how clumping stuff with | will impact ontological annotations. Still, for now I would be content to leave it to the user to work out useful If statements, and we would stop ourselves at demanding operable If statements.

Then, from the perspective of the engine, we would expect to construct a single if/elif/else clause all in a single shot something like

import pyiron_workflow as pwf

n = pwf.if_node(
    condition_node_classes=[KeyIfCondition, ...],
    body_node_classes=[IfBody, ..., ElseBody],
    if_condition_myinputtokeyifcondition=42,
    else_body_foo=789,
    elif4_body_bar="hello world",   # Assuming ... contains a 4th elif
    output_map: [None, ..., ("c", "b", "a")]
)
m = pwf.std.UserInput(n.outputs.result_2)  # Assuming the bodies have at least three outputs

Where the ... indicate that there may be a commensurate number more classes for the elif clauses, and I've demo'd wiring up some input too. I realized I also need to expose an output_map: list[tuple[str, ...]] with one tuple for each body node class, and one entry in that tuple for each expected output in the If node. In our example, suppose that IfBody has three outputs and we're happy with all of them (so the map is None), but ElseBody has five outputs ("a"..."e"), and of course we only need three and we want them in the order c-b-a.

For any engine which demands that node interfaces be available at the class level, we can validate the If node subclass at subclass definition time by counting return values on the body nodes, ensuring that mapping strings point to valid channels, that all the conditions have a single boolean return, etc. So this is pretty ugly, but I see it as robust, implementable, and clear (in that it is all very explicit, it is still complex). Producing such a beast with pretty and easy-to-write syntax is then the complexity I'm hoping to kick over to semantikon.workflow dataclass recipe generation 😉

...
So there are two if statements and one else which is attached to the first if. In this case, the first if statement gets the tag injected_If_0 and the second one injected_If_1, but the else becomes injected_Else_1, because it is associated with the second if. With this argument, elif should in principle be injected_Elif_i, but since there could be multiple of them, we might need one more index, so injected_Elif_i_j? What do you think? @liamhuber

In light of what I was saying for the engines, I think rather that we want to take the similar approach to injected_While and inject a single injected_If that encapsulates at least one if, and arbitrary number of elif, and creates an explicit else if there isn't one there already.

In that way, I think that your example does need indices on the injected_If_N, and the elif clauses also need an index, but I think we avoid double-indexing because instead any elif index is already nested _inside the injected_If.

I just realized one thing. With if - else we definitely have two sources for a node:

def f(x):
    if x < 0:
        y = g(x)
    else:
        y = h(x)
    return y

So y has the output of g or h, and the edges have to be given accordingly. It's not necessarily a problem, but goes against our paradigm.

Yes, we run into that in naked if statements too; consider your last example but both trimmed down and fleshed out:

def my_function(x):
    y = f(x)
    if some_condition(x):
        y = g(x)
    return y

I'm not sure how to represent this nicely the semantikon.workflow dataclass/JSON side. Normally our idea of a "macro" has both "nodes" and "edges". For "While" we already broke this up a bit, so that instead of just "nodes" we have a special "condition" node (or "test", tbh I don't remember and it doesn't matter). Perhaps for "If" we could follow the same generic attack, but specifying special "output_edges" where we know we are allowed to violate our single-source rule? (This is in addition to breaking "nodes" into "test" and "body" components, which we also need to do but is clearer and has definite precedent from "While")

Although I'm not sure how to get there, let me end with the goal I have in mind. I'd like to be able to parse this:

def always_works(x):
    a = f0(x)

    if c0(x):
        a = f1(x)

    if c1(x):
        a = f2(x)
        b = g0(x)
    elif c2(x):
        b = g1(x)
    else:
        _, b = g2(x)

    return a, b

When this gets converted into the recipe dataclass, I think I want it to parse into a macro containing two injected_If clauses. Note that the first if c0(x) should result in the implicit else giving back the a = f0(x) information. Note that the second elif/else clauses also need to capture whatever the result of the first if c0(x)/else injected_If gave. Note that the macro as a whole is clever enough to determine that a and b both definitively exist, and to pull them from the output of the second if/elif/else injected_If. Note that g2 actually returns more stuff than the other body "nodes", and I've thrown away the first output in favour of using the second (this populates the map in my engine example).

[liamhuber]

Oh man, note also that the second injected_If for its body nodes is actually on-the-fly creating macro nodes to populate the role. In the case of if this is clearly just of the form a, b = ifmacro(x), but for the others we need the same number of outputs but are implicitly using the sibling a result a, b = elifmacro(x, a_inp) where this macro internally contains an identity/otherwise maps the a_inp directly back out to the a return! That means the second injected_If needs two inputs, not just x! Thus, the edges for the always_works macro should contain something like [..., ("inputs.x", "injected_If_1.inputs.x"), ("injected_If_0.outputs.result_0", "injected_If_1.inputs.a"), ...]

[samwaseda]

Yes, we run into that in naked if statements too; consider your last example but both trimmed down and fleshed out:

def my_function(x):
    y = f(x)
    if some_condition(x):
        y = g(x)
    return y

I was about to say that in this example that's not the case, but I then realized that it doesn't have to be the case with my example either, but I'm not really sure if that's a sensible thing to do. The reason why this is (at least in my current implementation) not the case is because y goes into the injected-if and then to outputs.y. If some_condition does not apply, then y comes out unchanged, just like in the case of while or for. In this regard, we "could" represent my example as x -> injected_if -> y -> injected_else -> outputs.y. The problem here is that else does not have test, meaning whether the body of the else-statement is performed or not depends on the result of the previous if or elif statement.