#239 Handling linear cyclic graphs

[Jacob Bayless]

Hello,

I come from a control engineering background but I'm a newbie to Minsky, so please take this feedback with a grain of salt. I'm coming here with fresh eyes but probably I have a wildly different intuition for how I want to solve a problem with Minsky than someone with more experience might have.

There are multiple, algebraically-equivalent ways to construct a differential equation, including some with loops. For a very simple example, let's say I have this equation:

y = x + 0.5y

If I try to naively draw this in Minsky, I'll get the error message "cyclic network detected" and "maximum recursion order reached". Of course this equation is easily solved, because it can be rearranged into a simpler form: y = 2x. In this form, the equation doesn't have any loops.

It seems that Minsky has a symbolic math backend, so it should be possible for it to handle at least some cyclic networks, so that users can have more flexibility in how they define a system.

"Okay but clearly the user shouldn't be defining a system like that", you say. Maybe.

Perhaps I'm modelling an electrical RC circuit. I could construct this equation like this:

current = (vin - vout)/R
vout = integral(current/C)

Minsky is happy with this.

But another mathematically valid description of the same circuit is the equation:

vout = vin - d/dt(vout / RC)

There is nothing fundamentally wrong with this equation, but Minsky is not happy with it. If I implement it with two instances of the "vout" variable, it fails silently, claiming (incorrectly) that vout is always zero. If I instead wire the difference back to the input of vout, it complains about a cyclic network and refuses to run the model. In this case, unlike y = x + 0.5y, this is a perfectly valid differential equation and it might not be at all obvious to a modeller how they should rearrange the equation to avoid cycles.

I assume that Minsky is really looking to solve an integral equation, rather than a differential equation, and probably relying on there not being any feedback terms that aren't in integral form. However, at least in the case of linear operations, it should be possible to reduce them all to an equivalent input-output transfer function using Mason's rule, regardless of how many nested cycles there are. It's not a huge leap from there to automatically transform a system modelled with a differential equation into an equivalent integral form, without forcing the user to rearrange the model themselves.

But I'm really brand-new to this software, so maybe I'm missing the obvious "fix cycles" button that already solves this problem?

[Steve Keen]

Firstly, welcome Jacob: it's a pleasure to have someone from a control engineering background giving feedback on Minsky.

Russ will give you the programming answer here; from my user/designer perspective I can speculate that this could be addressed by editing the cyclic network error check to look to see whether the problem is a valid instance like this, or an invalid instance of someone unintentionally setting up an infinite algebraic loop.

[High Performance Coder]

Minsky is designed to integrate first order differential equations where the derivative is on the left hand side. As such, it readily handles integral operator on the right hand side by effectively adding another differential equation. Cycles are also OK, so long as the cycle passes through an integral, which breaks the cycle at the integration variable.

The derivative operator (which I kind of resisted at the time, since I knew it would create problems) symbolically differentiates the input expression until it gets to an integral (which it just reduces to its input), a constant (which it substitutes 0) or the time operator, which it substitutes 1.

Clearly putting a derivative operator in a graph cycle undoes effect of the next integral it encounters, so any cycles passing through a derivative operator must pass through at least two integrals. Obviously, when this restriction is exceeded by a user, Minsky needs to put up an error message, which by the sounds of this, and Ty's PID controller example, is not happening.

Yes - it might be nice to handle arbitrary differential equations, but to do that in full generality would require an engine like Mathematica, Maple or Maxima. Even then, there is no general algorithm, rather these packages are collections of algorithms devised to date, which expand over time. We could potentially limit the work to low order linear differential equations - second order would not be too hard for example, but I'd like to see significant use case before breaking out the code editor.