Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

# Non-shortcircuiting if_else should be default for MX #1968

Closed
opened this issue Mar 7, 2017 · 5 comments

Projects
None yet
3 participants
Member

### jaeandersson commented Mar 7, 2017

 The shortcircuiting `if_else` for MX is error prone. I think we should change the default behavior to be `non-shortcircuiting`, just like for SX. Then, if you really want short-circuiting, you have to specify this. Or work with Function instead (which might be much cleaner). Cf. #1967 ```from casadi import * c = SX.sym('c') x = SX.sym('x') y = SX.sym('y') print(if_else(c, x, y)) # ((c?x:0)+((!c)?y:0)) c = MX.sym('c') x = MX.sym('x') y = MX.sym('y') print(if_else(c, x, y, True)) # switch(c, x, y){0} print(if_else(c, x, y, False)) # ((c?x:0)+((!c)?y:0)) print(if_else(c, x, y)) # switch(c, x, y){0} <=== change this```

Member Author

### jaeandersson commented Mar 7, 2017

 @ghorn @jgillis Agreed?
Member

### ghorn commented Mar 7, 2017

 Is the error-proneness is orthogonal to the decision?
Member Author

### jaeandersson commented Mar 7, 2017

 Is the error-proneness is orthogonal to the decision? Currently, the default behavior for MX (but not SX), is that when it encounters an expression such as ``````if_else(c, , ) `````` to identify the primitives in the expressions and construct functions that are passed to the Switch node. This can lead to unnecessary recalculations in very simple cases, like: ``````x = y = x + 1; if_else(c, x, y) `````` It's better that the default for MX is the same as the default for SX, which is also less error prone.
Member

### jgillis commented Mar 8, 2017

 I have no opinion of this. If your model needs switches, you must be doing it wrong he;-)
Member Author

### jaeandersson commented Mar 10, 2017

 OK, I'll go ahead with this then. Not sure if we need a soft deprecation for this... maybe not.

### jaeandersson added a commit that referenced this issue Mar 30, 2017

``` Issue #1968: No default value for short_circuit in if_else ```
``` 20e98ab ```

### jaeandersson added a commit that referenced this issue Mar 30, 2017

``` Issue #1968: No default value for short_circuit in conditional ```
``` 2ff694b ```

### jaeandersson added a commit that referenced this issue Mar 30, 2017

``` Issue #1968 Fixed lint ```
``` 7e17dd6 ```

### jaeandersson added a commit that referenced this issue Mar 30, 2017

``` Issue #1968 short_circuit=false default for if_else,conditional ```
``` 9f1521d ```

### jaeandersson added a commit that referenced this issue Mar 30, 2017

``` Issue #1968: No default value for short_circuit in Python ```
``` 9e2527a ```

### jaeandersson added a commit that referenced this issue Mar 30, 2017

``` Issue #1968 short_circuit=false default for if_else,conditional in Py… ```
`…thon`
``` bd11769 ```

### jaeandersson closed this Mar 30, 2017

to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.